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.

  • You know that you domain is complex enough to justify DDD when you use DDD to model it. :) Feb 10, 2011 at 19:27

1 Answer 1


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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