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.

  1. 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.

  2. 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.


1 Answer 1


To be honest, your question is not easy to understand.

When you start your DDD journey, you identify your domains and bounded contexts. Ideally you have one bounded context per domain but it depends. Each domain has its own domain model, you mention this yourself. But these domain models have nothing in common. They don't know about each other. Your idea to have one base class for two entities from different domains does not fit to DDD. Real domain models do not allow accessing anything within the domain model to anything outside of the bounded context. All communication between bounded contexts go via pre-defined interfaces like queries and commands if you do CQRS. This way you can make your components loosely coupled and allow different groups to work on different domains without depending on each other.

Bounded context always mean separate application. You can think of a separate solution though. It will include a domain project with entities, VOs, commands. It will also include services project with command handlers and query handlers. It will include transport projects like an application that uses service bus for commands and events.

Remember that using domainevents is crucial to enable inversion of control on the business logic level, when one domain informs everyone else about things that happen, allowing the, to react accordingly and do necessary activities. You can think of order payment event in sales domain that triggers a dispatching process in the inventory domain. Sales domain does not even need to know about the inventory domain.

  • I tried to clarify my question. I think you answered it, since each BC has it's own entire "domain" with Services/Entities/Repository. The BookId class was trying to demonstrate the shared identity between BCs so each BC refers to the same book (although they shouldn't have direct access to it's properties/behavior from another BC). I was trying to figure out how to physically model BCs and domains/sub domains and now the role of the BC is clear.
    – lko
    Commented Oct 14, 2013 at 18:26

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.