I've recently started studying Domain Driven Design and so far it looks like it will help tremendously with my team's current project. I'm running into a bit of a problem though actually determining what the domains are in our project.

After my inital pass, I ended up with something like this:

Domains D & E overlapping A,B,C

I have three domains: A, B, and C for different areas of the business. However, for each of those I need to track current data as well as create plans for the future. This led me to add a Planning domain, but I don't see a clear way to separate Planning from the other domains. Either A, B, and C need to have detailed knowledge of Planning or vice versa.

Example: Let's say Domain A is "inventory". The implementation has messages for things like ItemsAdded and ItemsRemoved and it tracks quantities of various products. Then if I want to allow for planning of future quantities of items I need to add classes to the model which will allow me to associate future product info with various time windows. This kind of feels like a new domain except the same planning and time window logic also applies to Domain B and C.

Essentialy, I have a cross-cutting domain. I feel like I must be looking at this the wrong way.

Maybe I actually have 6 domains and a library used by 3 of them?

  • There should be just one domain, but you can have multiple bounded contexts, aggregates or domain objects. Which of these are your "domains"? – zafarkhaja Jul 9 '14 at 5:26
  • I assume he means bounded context when he says "Domain". – Euphoric Jul 9 '14 at 6:25
  • Have you read Domain-Driven Design? The book is filled with advice and strategies for integration between bounded contexts. – Benjamin Hodgson Jul 9 '14 at 7:54

Cross-cutting domain can be a symptom of Shared-Kernel Domain. This is covered both in Evans' and Vernon's books.

But be careful, this Shared-Kernel domain should not be created by functional inspiration, but a domain which contents are relevant to other domains - and not because it does something useful for both.

It is tempting to create a Shared-Kernel domain that fulfils a functional role, therefore making the system tightly coupled instead of loosely coupled. A big no-no for source code scalability.


What is stopping you from creating a "Planning Domain" and have other 3 depend on this domain? This seems quite normal dependency in library/module.

  • A business domain is not associated with a library/module. Having dependencies to entities of another business domain defeats the purpose of bounded contexts. Even shared kernel domains may eventually need to be split into multiple business domains. – Orestis P. Oct 27 '18 at 10:57

Off course i don't understand your domain with enough info, but planning sounds for me like a domain completely separated from the rest of your system.

This domain have the operations/rules/behaviors for planning things, for example, you can plan items from your inventory, but from the planning point of view this are not "inventory items" are something like "planItems" perhaps. Probably you don't need all the information of a inventory item for planning, why do you want to use this inventory item classes in your planning domain?

For me this is one key thing to understanding DDD and do a proper separation in bounded contexts, the same "thing" can be viewed completely different from different domains, you can have a InventoryProduct in the inventory domain and a PlannedProduct or PlannedItem in the Planning domains, this objects can have the same id or perhaps share a very little set of fields (Identification information like id, name etc,etc) but have completely different set of operations and completely different data, in one case the data that the inventory needs in the other case the data that the planning needs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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