Skip to main content
Maybe I should stop reading stuff about #DDD (=Domain Driven Design). I read https://thevaluable.dev/anemic-domain-model/ and now I question so many parts of previously written code. I again want to experiment and get a feeling on how this might work out.

I probably should read "Domain-Driven-Design" from Eric Evans again and again.

How does it work for you? How do you handle situations where you learn something new and need to give it a try? How do you handle your old code?

Anemic Domain Model vs Rich Domain Model with Examples

The comparison between adding the behavior of your domain to your entities (rich model) or to services (anemic model).
Matthieu Cneude
#DDD
Simon Praetorius
I always felt bad doing this. Maybe it isn‘t that bad after all. thanks for the input!

Concerning refactoring I usually leave the old code as-is if it doesn‘t have a lot of links to other parts of the application that use the new way. Also, the new way might be the old way soon again. For example if you read the heated arguments in the blog post‘s comments. 😄
Daniel Siepmann
For me it is not only about refactoring. But also about adding new code once I've learned something new.

I currently think that it is more important to have a single structure than to have the current best implement. And I also believe it is a bad idea to try out things on customer projects. It is better to have some small pet project to experiment.
Simon Praetorius
I think in this case it is fine to use both model variants in one project, as long as they are reasonably decoupled.

I tried some new ideas in customer projects in the past. Some went very well, some… not so much. In my experience, an early failure in a client project is still better than long isolated development in a pet project. It‘s probably an individual decision to make. 🤷🏼‍♂️
Alexander Schnitzler
I am team aenemic (due to limits of the extbase framework) and go for domain events instead. Those handle the domain logic based on actual user events. https://learn.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/domain-events-design-implementation

But I have to say that I don’t do everything 100% by the book and continue to learn what‘s possible and sensible.

Domain events: Design and implementation

.NET Microservices Architecture for Containerized .NET Applications | Get an in-depth view of domain events, a key concept to establish communication between aggregates.
learn.microsoft.com
This entry was edited (2 weeks ago)
Daniel Goerz
@alexanderschnitzler
In more complex applications, I use (context aware) DTOs when retrieving Data from a request or from the Database. I also use DTOs to be handed to the view sometimes.

My Domain Models have factory methods that take those DTOs as an argument and the domain logic lives in the Models.
@Alexander Schnitzler
Daniel Siepmann
Didn't hear Domain Events until now … so something new I need to check out as well … :)
DaFrank
For me it is always a constant process to improve my work over time. For smaller customer projects it is not always feasible to refactor everything to adhere to the 'new way'. But it is also an advantage as I can go project by project and improve my personal skills. When I look then at my old code I can see the progress. Of course I can not go full into the new doctrine full speed, but I learned to pick what works best for me and the environment I work with..
DaFrank
I rather know stuff I don't use than not knowing the stuff I use ;)
Dan Leech
you can use new knowledge on old code with out refactoring it all, e.g. it costs little to nothing to introduce value objects and DTOs.
Dan Leech
for giving it a try I try and do this on a personal project first - the chance to actually do some of this stuff "at work" is practically limited anyway, but some of it can be applied anywhere.
Helmut Hummel
Every line of code I write, every line of code I read, every single article or page I read influences how I am thinking about and actually writing code.
This means I automatically try new things in the current project, being it side, customer or OSS.
It does NOT mean rewriting everything from scratch over and over again or trying things that does not scale with the problem to solve.

My priorities:

1. solve the problem
2. make the code easy to change

(easier said than done)

2 people reshared this

Daniel Siepmann
That are also always my two priorities. But it constantly changes how I try to achive both. As you wrote: One constantly evolves and so does the way to achieve the goals.
⇧