design-patternsdomain-driven-design

Using a lot of service classes in a domain model is a sign of what


I have recently tried practicing DDD and i found my self going towards lots of domain model objects that are pure data structures with no behavior and lots of services in the domain model and i would like to know if this is a sign of bad design, influence of architecture (Entity Framework) on my design or using the wrong technique to develop this kind of application, i think it is a 90% CRUD application.


Solution

  • The percentage of domain services is not a useful metric of the quality of a domain model.

    But "pure data structures with no behavior" are code smells, if you need a domain model.

    Now, you need a domain model if the business handled by your application is so complex that you need a domain expert to understand it. There are very few applications that requires DDD (Evans once stated just 5%), but they are often high budget ones. Such budgets come from two considerations: the high complexity of the business and the competitive advantage that the stakeholder obtains from them.

    Even the percentage of the domain classes over the full project is not a useful metric: for example, in a CQRS application you will have a number of DTOs, but still you can have a good domain model that recieves commands. Moreover, it's fine to have a 90% CRUD application that, in a well bounded operative context, requires a domain model to enforce complex business invariants.

    However, if you don't need a domain expert, you probably don't need a domain model.

    If so, remember that Buzzwords Driven Development is very expensive.
    You should not "try" to use DDD if you don't really need it.