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:
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?
3
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.
1
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.