How do you formulate the Domain Model in Domain Driven Design properly (Bounded Contexts, Domains)?
- by lko
Say you have a few applications which deal with a few different Core Domains.
The examples are made up and it's hard to put a real example with meaningful data together (concisely).
In Domain Driven Design (DDD) when you start looking at Bounded Contexts and Domains/Sub Domains, it says that a Bounded Context is a "phase" in a lifecycle.
An example of Context here would be within an ecommerce system. Although you could model this as a single system, it would also warrant splitting into separate Contexts. Each of these areas within the application have their own Ubiquitous Language, their own Model, and a way to talk to other Bounded Contexts to obtain the information they need.
The Core, Sub, and Generic Domains are the area of expertise and can be numerous in complex applications.
Say there is a long process dealing with an Entity for example a Book in a core domain. Now looking at the Bounded Contexts there can be a number of phases in the books life-cycle. Say outline, creation, correction, publish, sale phases.
Now imagine a second core domain, perhaps a store domain. The publisher has its own branch of stores to sell books. The store can have a number of Bounded Contexts (life-cycle phases) for example a "Stock" or "Inventory" context.
In the first domain there is probably a Book database table with basically just an ID to track the different book Entities in the different life-cycles.
Now suppose you have 10+ supporting domains e.g. Users, Catalogs, Inventory, .. (hard to think of relevant examples).
For example a DomainModel for the Book Outline phase, the Creation phase, Correction phase, Publish phase, Sale phase.
Then for the Store core domain it probably has a number of life-cycle phases.
public class BookId : Entity
{
public long Id { get; set; }
}
In the creation phase (Bounded Context) the book could be a simple class.
public class Book : BookId
{
public string Title { get; set; }
public List<string> Chapters { get; set; }
//...
}
Whereas in the publish phase (Bounded Context) it would have all the text, release date etc.
public class Book : BookId
{
public DateTime ReleaseDate { get; set; }
//...
}
The immediate benefit I can see in separating by "life-cycle phase" is that it's a great way to separate business logic so there aren't mammoth all-encompassing Entities nor Domain Services. A problem I have is figuring out how to concretely define the rules to the physical layout of the Domain Model.
A. Does the Domain Model get "modeled" so there are as many bounded contexts (separate projects etc.) as there are life-cycle phases across the core domains in a complex application?
Edit: Answer to A.
Yes, according to the answer by Alexey Zimarev there should be an entire "Domain" for each bounded context.
B. Is the Domain Model typically arranged by Bounded Contexts (or Domains, or both)?
Edit: Answer to B. Each Bounded Context should have its own complete "Domain" (Service/Entities/VO's/Repositories)
C. Does it mean there can easily be 10's of "segregated" Domain Models and multiple projects can use it (the Entities/Value Objects)?
Edit: Answer to C. There is a complete "Domain" for each Bounded Context and the Domain Model (Entity/VO layer/project) isn't "used" by the other Bounded Contexts directly, only via chosen paths (i.e. via Domain Events).
The part that I am trying to figure out is how the Domain Model is actually implemented once you start to figure out your Bounded Contexts and Core/Sub Domains, particularly in complex applications. The goal is to establish the definitions which can help to separate Entities between the Bounded Contexts and Domains.
