Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When assessing a potential project at work, I suggested that it might be advantageous to use a domain driven design approach to its object model. The project does not have an excessively complex domain, so my coworker threw this at me:

It has been said, that DDD is favorable in instances where there is a complex domain model (“...It applies whenever we are operating in a complex, intricate domain” Eric Evans).

What I'm lost on is - how you define the complexity of a domain? Can it be defined by the number of aggregate roots in the domain model? Is the complexity of a domain in the interaction of objects?

The domain that we are assessing is related online publishing and content management.

share|improve this question
You know that you domain is complex enough to justify DDD when you use DDD to model it. :) – Adam Crossland Feb 10 '11 at 19:27

The complexity of the business logic, alternatively called the application behavior, is the most important factor. The second most important factor is how much of a gap there is between the technical problem and the business vocabulary used to describe that problem, since DDD is about creating a shared vocabulary between the business and the engineering team.

Some of the patterns used in DDD are generally useful in enterprise application architecture, such as the Repository pattern, Bounded Context, and Layered Architecture. Just because you're using those patterns, doesn't mean you're doing domain driven design.

If there's not much behavior, which is to say, you're mostly storing data, and not acting on that data, there may be much less value in building out that domain layer. In content management, if all you do is approve and publish, maybe that can be represented by flags in the system, rather than domain methods. But when you start adding additional behavior, the appropriateness of a full-on domain layer becomes more apparent.

If we're talking about content management, here are some (imagined) rules that might start to hint at the need for DDD:

  • If story is embargoed until date xx/yy/zz, publish to print, then to web; if there's no embargo, publish to web and make available for print
  • Make this story available behind the paywall to paid subscribers immediately; release to the general public 2 weeks later.
  • After a story is written, send it to an editor for revision, proofreading, and approval. When approved, send it to production. If production cuts up the story for space reasons, make an extended version available online.
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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