How Models and Bounded-Contexts are mapped into the codebase DDD?

Question

Models and Bounded-Context conceptually are:

Model:

A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.

Bounded-Context:

The setting in which a word or statement appears that determines its meaning.

But I have to questions:

1. Is the relationship between the two is containment relationship, i.e. Bounded-Context has one or more models?

2. As I understand DDD concepts should be identifiable (to some degree) through the codebase, this is clear for Aggregate, Entities, Event, Commands...etc, but how Models and Bounded-Context are mapped into the codebase? for example is a models just a set of one or more aggregates, or something else? is Bounded-context a namespace or something else?

Thanks in advance.

Note: Feel free to state your answer in term of some framework, Django, Axon..etc.

Answer 1

Is the relationship between the two is containment relationship, i.e. Bounded-Context has one or more models?

I guess you could say it that way, but a bounded context (BC) has just one model, with objects named according to the ubiquitous language (UL) of the BC.

Both models and BCs belong to the solution space.

In the problem space you have the domain and sub-domains.

In the solution space you have BCs (ideally 1:1 related with sub-domains). You model a subdomain, and you have a BC for each sub-domain model.

But for example you could model the entire domain with just one model, so that you would have just a BC in the solution space for the entire domain. In this case you have one BC related to many subdomains. This BC would be a monolithic application.

The other example, one sub-domain related to many BCs, happens when you split the sub-domain into several "parts", and you model each "part". So you would have many models for the subdomain. This way in the solution space you have many BCs for the subdomain, i.e., many applications to solve a subdomain problem.

These cases of 1:N or N:1 relationships between subdomains and BCs happens when the division according to the UL terminology is fuzzy.

As I understand DDD concepts should be identifiable (to some degree) through the codebase, this is clear for Aggregate, Entities, Event, Commands...etc, but how Models and Bounded-Context are mapped into the codebase? for example is a models just a set of one or more aggregates, or something else? is Bounded-context a namespace or something else?

A BC is a software system, an autonomous application. And a model is the source code of the BC. But in DDD there exists another concept: the module, a cohesive group of domain objects. It is a thinner division than BCs.

So you have, from wider to smaller:

Solution --> BC --> module --> aggregate --> entity & value objects

Answer 2

This is based on my understanding of course... opinions may vary.

1. Model is not one thing in your code but if done well, it is the code. It is what you come up with from the knowledge crunch of the business and try and capture in code. Coming up with one model for the whole business is usually a fool errand. So you have a context that the model is valid in...
2. A bounded context is a context that a model is valid. This is valuable for a few reasons. It allows us to manage the scope and complexity of a model. A model is only useful insomuch as it helps us solve business problems. To do this we need to be able to keep some form of it in our heads so we can understand. This is where language comes in. The language, aggregates, etc. are valid for that context. I like to use an example here. A product in an eCommerce checkout is different from a product being picked from a warehouse. They may share some concepts but some are not relevant across contexts. How they relate should be captured in a context map.