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

In DDD i struggle to understand whether or not my domain is split correctly into aggregate roots and then those aggregate roots are grouped correctly into bounded contexts. is there a way - like a set of rules/guidance i can use to decide whether or not i am placing things in the right AR/BC

share|improve this question
Please add more details – user2567 Jun 30 '11 at 13:01
You know when you look back on it in about 12 years. – Affe Sep 17 '11 at 20:40

I think Udi Dahan gives a fantastic answer on DDD and creation of aggregate roots:

As stated by @Malvolio you need to figure out what problem you are trying to solve then decided on how the situation maps back to the real world. Once you have this then the aggregate root will become clear and obvious.

share|improve this answer

They say that experience is the worst teacher because you get the test first and the lesson afterwards.

Your design decisions are ratified when the problem changes (or your understanding of the problem changes) and you don't have to rip out huge chunks of code and start over.

Of course, by then it's too late.

The best you can do proactively is ask yourself two questions:

  1. Does my design really represent my problem, in that basic, fundamental concepts in the problem space are represented by basic, fundamental concepts in the design and trivial, contingent features of the problem are incidental to the design as well?
  2. What if I'm wrong? What if some of the assumptions I have made in the design turn out to be wrong, or stop being right? What if an Employee is managed by a Contractor? Can a Invoice be empty? Is that just a new unit test or is it a major project?
share|improve this answer

My suggestion: don't design the aggregation roots, keeping refactoring the model and the aggregation roots will show themselves. When developing the system, you'll notice that some related entities are always being changed together, then you know they belongs to the same aggregation root.

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.