What problems do you find with this view on domain-driven design? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this question

I just wrote a long (and messy) blogpost about my view on domain-driven design at present day, with frameworks like开发者_StackOverflow中文版 spring and hibernate massively in use.

I'd ask you to spot any problems with my views on the matter - why this won't work, why it isn't giving the benefits of DDD, why it is not a good idea in general.

The blogpost is here (I don't think I need to copy-paste it on SO - if you think I should, tell me).

I know the question is subjective, but it is aimed at gathering the most predominant opinions.

(I'm tagging Java, since the frameworks discussed are Java frameworks)

---

I've just spent a year of my life ripping apart an application to eliminate an anaemic domain anti-pattern and its mis-use of Hibernate.

I can say without a doubt that the code that comes as a result of DDD is much easier to understand and refactor. In our case, the removal of a myriad unnecessary getters & setters, the increase in encapsulation, the concentrating of business logic, and resulting (dramatic) simplification of the services layers that come along with DDD have made the system so much more easy to maintain that now I believe we will be able to finish it, whereas before it was dragging on into forever. We've reduced the line count of this application by 50% without removing any functionality.

I also believe that the entire point of an ORM tool is so that my business logic is uncluttered with persistence code. When we had an anaemic domain model, we had a DAO for every domain class, now we have a small handful of DAOs as an entry point for CRUD on the "major" domain classes, but the other "minor" domain classes are handled by their parents...not because persistence logic is in the parent but because Hibernate transparently reacts to the business logic and makes everything Just Work.

In short, I can't answer this SO question because I emphatically agree with your post 100%...and am living it every day.

---

We go with the "anemic model" approach so that we can reuse the same models with different business logic. However, we do include calculations and helper methods within our models if they're applicable for all cases. But we do not inject anything into our models and do not inject our models into IoC.

---

Personally I'm not convinced that the part about injecting repository objects into the domain objects (meaning the persistent entities) is necessary with Spring and Hibernate. Hibernate is already providing persistent collections that can do lazy loading, so you already have the ability to traverse the domain model in a way that separates data-access infrastructure from business logic. I don't see what value tacking repositories onto the domain model is adding.

EDIT: Oops, posted this before reading the whole article. Now that I've read the entire blog post I think I'm in agreement with it. I like the part recommending doing without DTOs wherever possible.