A sub-domain belongs to the problem space.
A sub-domain may require multiple models. A bounded context belongs to the
solution space. Its purpose is to isolate a model from other models.
Problem:
A domain model is often not just a single
model, but several models, one or more for each sub-domain.
Models can grow in complexity.
Multiple teams working on a single model
can lead to inconsistencies.
Terms can have different meanings in
different parts of the model. For example, a customer might be a corporate
customer in one part of a model and a retail customer in another.
Replacing legacy models can be time
consuming.
Solution:
Each model should have a bounded context.
A model's context is its scope within a (sub-) domain. A bounded context is a
context encapsulated by a set of responsibilities and definitions.
Example:
The term "product" might have
slightly different meanings in different sub-domains: sales, inventory,
shipping, and marketing. This could mean different operations and attributes.
Rather than lumping all of them together in a single bloated class, we can
create multiple product classes, each in its own package: sales.Product,
inventory.product, shipping.product,
and marketing.product.