the problem with putting all busines logic in an aggregate root is that it can just blow up to 10k lines of code which becomes very hard to read and maintain.
Fair point. I've seen those scenarios where there's a single class used as the entrypoint of a massive portion of the domain. It becomes messy very quickly. I wonder though if in those scenarios there was a problem with the initial model. Maybe there was a better way to split concerns. Still every case has its own nuances.
That's good approach.I wonder if there should be separate db model irrespective of how similar is it from domain model? And, which approach is good to initialize and create domain model which may have near to hundred properties because a parameterized constructor or method would be overkill to handle hundred properties as parameters to create object?
If you leverage NoSQL you might be able to work by identifying Aggregates and storing them as Documents. It will save you the mapping from an object model to a relational one. Regarding the complex object construction I would use the "builder pattern". At the same time, I am also confident you can group some of those properties in Value Objects and avoid having all those properties at the same level.
Greetings from Argentina, I love your content, a question: does the correct use of valuable objects help to avoid anemic models? or I confuse my criteria, I'm learning. Thank you
Thank you 🙏 If the value objects are just holding data without enforcing any sort of invariant or business rule, the model is still considered anemic. The value objects help keep the model more readable and maintainable since you can group properties in a more descriptive manner rather than squashing everything together in a large entity. Have also a look at the latest video I did on aggregates to get a better idea.
@@MarcoLenzo I realised there was a mistake in my comment, “complete mess” should have been “completeness”! I have corrected it now. The closer you are to the centre of the application the more costly it is.
@@jwbonnett Yeah I had noticed the typo. However, your comment was very inspiring as I found good content on the DDD trilemma which is very interesting. I want to take some time to digest it. In my personal experience I've seen development teams opt for the split between decision-making process between the domain layer and controllers (or an additional "service" layer between controllers and the domain layer). It seems to be a common (and advised) approach. I think the only issue is that it's often taken to an extreme. While it's fine to avoid out-of-process dependencies in the domain, I think it is taken to a a stage where no business logic at all resides in the domain. As you said, you have to get the balance right which (possibly) makes it art more than science... 🤔
the problem with putting all busines logic in an aggregate root is that it can just blow up to 10k lines of code which becomes very hard to read and maintain.
Fair point. I've seen those scenarios where there's a single class used as the entrypoint of a massive portion of the domain. It becomes messy very quickly.
I wonder though if in those scenarios there was a problem with the initial model. Maybe there was a better way to split concerns. Still every case has its own nuances.
That's good approach.I wonder if there should be separate db model irrespective of how similar is it from domain model?
And, which approach is good to initialize and create domain model which may have near to hundred properties because a parameterized constructor or method would be overkill to handle hundred properties as parameters to create object?
If you leverage NoSQL you might be able to work by identifying Aggregates and storing them as Documents. It will save you the mapping from an object model to a relational one.
Regarding the complex object construction I would use the "builder pattern". At the same time, I am also confident you can group some of those properties in Value Objects and avoid having all those properties at the same level.
Greetings from Argentina, I love your content, a question: does the correct use of valuable objects help to avoid anemic models? or I confuse my criteria, I'm learning. Thank you
Thank you 🙏
If the value objects are just holding data without enforcing any sort of invariant or business rule, the model is still considered anemic.
The value objects help keep the model more readable and maintainable since you can group properties in a more descriptive manner rather than squashing everything together in a large entity.
Have also a look at the latest video I did on aggregates to get a better idea.
Entity Framework introduced this in its ORM code first design where all the properties of an entity had to be publicly accessible.
I've never used that framework to be honest.
What's your approach when using ORM? One model for business logic and persistence or separate ones?
Does your team produce anemic models? If not, which strategy are you using to embed business logic in your domain model?
The problem with a completeness is that you sacrifice performance, this is part of the DDD Trilemma! You have to get the balance right.
You gave me a very interesting point to think about! I will try to cover this point in some future video. Thank you very much for the feedback!
@@MarcoLenzo I realised there was a mistake in my comment, “complete mess” should have been “completeness”! I have corrected it now.
The closer you are to the centre of the application the more costly it is.
@@jwbonnett Yeah I had noticed the typo. However, your comment was very inspiring as I found good content on the DDD trilemma which is very interesting. I want to take some time to digest it.
In my personal experience I've seen development teams opt for the split between decision-making process between the domain layer and controllers (or an additional "service" layer between controllers and the domain layer). It seems to be a common (and advised) approach. I think the only issue is that it's often taken to an extreme. While it's fine to avoid out-of-process dependencies in the domain, I think it is taken to a a stage where no business logic at all resides in the domain.
As you said, you have to get the balance right which (possibly) makes it art more than science... 🤔
Thank you for the video
Thank you!
LOL, gotta love the Kung Pow references!
Great video as usual
Lol I was laughing so much while editing it 😂