20.1 Strategic DDD: Subdomains, Bounded Contexts, and a Shared Language

Domain-Driven Design (DDD) begins not as a set of code patterns like Entity, Value Object, or Aggregate, but as a collaborative method for understanding complex business domains and establishing clear boundaries for modeling.

If the team fails to co-define the language and boundaries with domain experts, adding the AggregateRoot annotation to a class will not automatically generate a domain model.

Domain and Subdomains

A domain is the business world an organization needs to solve. A subdomain breaks it down into parts with distinct problems and capabilities:

• Core Domain: Creates competitive advantage and warrants the highest modeling investment;
• Supporting Subdomain: Necessary for business operations but not a primary source of differentiation;
• Generic Subdomain: Industry-standard capabilities, typically acquired through off-the-shelf solutions or reusable frameworks.

In a competition platform, "Matchmaking and Tournament Rules" might belong to the core domain; notifications could be a supporting subdomain; identity authentication might use a generic product. Review this classification as strategy changes. A subdomain describes a division of business problems; a bounded context describes where a particular model applies. They are different views. Do not draw services from an organization chart and then name every box a subdomain.

Ubiquitous Language in Code and Conversation

Ubiquitous Language should appear simultaneously in:

• Daily discussions between domain experts and developers;
• Example requirements and acceptance criteria;
• Class names, method names, event names, and error messages;
• Monitoring, operations dashboards, and support documentation.

For instance, terms like "enroll," "reserve," "verify eligibility," and "withdraw" must be clearly distinguished. If the product team says "confirm enrollment" but the code refers to updateStatus(3), the translation has already been lost in the process.

Ubiquitous Language is not a single dictionary for the entire company. The same word may carry different meanings in different business contexts. Bounded contexts make those differences explicit.

Bounded Contexts Protect Model Meaning

In the "registration" context, Player cares about entry eligibility and seed rankings; in the "settlement" context, AccountHolder cares about payment identity and risk status. Forcing two contexts to share a single class with dozens of fields, Player, only results in tight coupling.

Registration Context          Settlement Context
Player                        AccountHolder
- eligibility                 - paymentIdentity
- seed                        - riskStatus
- registrationStatus          - balance

A bounded context defines the scope within which a model and language are effective. It typically maintains its boundary through explicit code modules, data ownership, and public contracts, but does not need to correspond one-to-one with microservices. A modular monolith can contain multiple bounded contexts, and a large context might also include multiple deployment units due to runtime considerations.

Discovering Boundaries from Business Events

You can map out real-world workflows by identifying:

• Commands: Who wants to do what;
• Domain events: What business facts have actually occurred;
• Policies: What decisions are triggered by observing a fact;
• Invariants: Rules that must never be violated;
• External systems and manual decisions.

For example:

Submit registration
  → Eligibility verified
  → Slot reserved
  → Payment authorized
  → Registration confirmed

If each step is managed by different teams, languages, or data schemas, context boundaries may emerge. If these steps must evolve together within a single atomic rule, premature decomposition can introduce distributed consistency challenges.

Workshops like Event Storming can help surface these patterns, but colored sticky notes are not final architecture. The conclusions must be validated against code dependencies, data ownership, organizational responsibilities, and operational constraints.

Context Mapping Describes Relationships

Contexts are not simply connected by arrows. Common relationships include:

• Partnership: Both parties jointly plan and evolve together;
• Customer–Supplier: Downstream requirements feed into upstream planning;
• Conformist: The downstream directly adopts the upstream model;
• Anti-Corruption Layer: The downstream translates and shields its own model;
• Open Host Service + Published Language: The upstream offers a defined service protocol and a shared, documented language for exchanging data;
• Separate Ways: Integration value is insufficient; each side implements independently.

Here "public" means a contract exposed to integration partners, not anonymous internet access. Sharing an exchange schema does not require sharing internal domain classes.

The same upstream can establish different relationships with different downstreams. Relationships should also specify contracts, SLAs, responsibilities for upgrades, and deprecation.

Questions for Evaluating Boundaries

• Are these rules explained by the same group of domain experts?
• Does the same term have different lifecycles or invariants in two different places?
• Who writes the data, and who has the authority to correct it?
• Which changes frequently occur together?
• Can a single team own this capability end-to-end?
• Are strong-consistency invariants split across boundaries?

The next lesson looks inside a context, using entities, value objects, and aggregates to express business invariants.

References

• Martin Fowler, Bounded Context
• Martin Fowler, Ubiquitous Language
• Eric Evans, DDD Reference