Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am looking for some well structured samples implemented using Domain Driven Design that include a rich Domain model. Currently I tend to design systems with Anaemic Domain Model and according to many such as Fowler that is an anti-Pattern and I should be looking to have a Rich Domain Model instead of having the model behaviour contained inside Service classes.

The issue I am running into is that there seems to be a wealth of "Domain Driven" examples out there that do not have Rich Domain Models and I was looking for some that do for comparison. Preferably in C# but any language is likely relevant. I am interest in

  1. How it is structured
  2. Where behaviour should live
  3. In what cases its appropriate to have the behaviour in a service class.
  4. How you deal with business logic that may vary for the same model depending on usage
share|improve this question

closed as too broad by MichaelT, GlenH7, Dan Pichelman, Kilian Foth, Corbin March Sep 11 '13 at 13:01

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

add comment

1 Answer

I don't really think there exist such example. Most DDD examples are really simple applications. Also, it is quite bad trying to use specific structure, without understanding why it was done that way.

If I were to develop such system, I would go according to these principles:

  1. Make sure the domain model is separated from rest of the system, unit testable completely by itself and it is possible to reason about it without any other part of the system. Of course, there might be problems like persistence leaking into the model, but it can be minimized with proper use of the ORM or specific type of DBs.
  2. Make every other part of application depend on this model. Application, UI, persistence should all depend on model. Not other way around, that is especially for persistence.
  3. Try to adhere to SOLID when making the model and make use of all known design patterns (strategy is quite good with domain models).

To answer your other 3 question. It all depends on how you define behaviour, what you mean by service class and what does it mean that business logic may vary for the same model. To me it sounds you are trying to put something, that should be in domain model, in some other part of the application.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.