Recommended resources
The freely available resources this lesson will direct you to.
Hello! Last lesson turned a workshop reservation brief into observable requirements, including a crucial rule: two members competing for the last place must not both receive confirmation. This lesson asks a different question: where should the business rules and decisions live?
You’ll trace the reservation workflow, look for changes in business language, and use invariants—rules that must remain true—to propose domain boundaries. The goal is not to decide how many services to deploy. It is to identify parts of the business that need coherent models and clear ownership.
Start with the work the business performs
A list of nouns can be a poor starting point for architecture. Workshop, member, and reservation might become database tables, but their names alone do not tell you which rules belong together. Follow the work instead.
For the brief from last lesson, a provisional workflow is:
- An organizer makes a workshop available for members to find.
- A member views its details and the currently displayed number of places.
- The member requests a place.
- The system either confirms a reservation or explains why it cannot.
- The member views the resulting reservation.
“An organizer makes a workshop available” is a working assumption for exploring the domain, not a requirement established by the brief. Likewise, cancellation, payment, and a limit of one reservation per member remain outside this workflow until someone confirms they are needed.
The workflow exposes different decisions. Someone determines the workshop’s descriptive details. Someone decides whether a request can consume a place. Someone determines whether the signed-in member may view a particular reservation. Those decisions may involve the same person or record without belonging to the same domain model.
Watch how the following example separates a product’s meaning across different business activities.
Practical DDD: Bounded Contexts + Events = Microservices
Watch Practical DDD: Bounded Contexts + Events = Microservices from InfoQ for a concrete explanation of why one universal model becomes awkward, then for the speaker’s boundary-finding heuristics.
Watch conflicting meanings as sales and logistics use “product” differently. Continue through bounded contexts, focusing on why each model can use precise local language. In boundary heuristics, note the question about transactional consistency—but treat it as evidence to investigate, not a mechanical rule that determines every boundary.
A bounded context is a part of the domain within which terms and rules have a consistent meaning. It is not necessarily a separately deployed application. In our example, “available places” on a workshop page is information shown to a member; “can this request be confirmed?” is an admission decision that must remain correct even if the page’s displayed count has become stale. Using one vague available property for both meanings invites mistakes.
Turn the workflow into candidate contexts
Microsoft’s domain-analysis guide offers a useful order of operations: map business functions and their dependencies before selecting technologies, then ask where distinct models apply.
Using domain analysis to model microservices
Read Microsoft’s Using domain analysis to model microservices for its method of finding business groupings and its explanation of bounded contexts. Despite the title, use it here to discover domain boundaries, not to commit to microservices.
In “Analyze the domain,” begin where the article says to understand the system before writing code. Read the mapping guidance, paying attention to related functions, business importance, and dependencies. Then, in “Define bounded contexts,” read the model discussion. Notice why the same real-world thing can have different representations and why interactions between contexts must still be identified.
A subdomain is an area of business capability, such as managing workshops or handling reservations. A bounded context is the boundary within which software uses a particular model of that area. The distinction matters: business capabilities help you discover candidates; a bounded context specifies where a vocabulary and its rules apply.
For the workshop feature, two candidate contexts are:
| Candidate context | Decisions and language it owns | Information it needs from elsewhere |
|---|---|---|
| Workshop Planning | What the workshop is, when it occurs, and whether it is published | Reservation information if planning decisions depend on committed places |
| Reservations | Whether a request can be confirmed, which places are committed, and who owns a reservation | The workshop’s identity and an approved booking limit |
An existing Accounts context might establish who the signed-in member is. That does not move reservation privacy into Accounts: Reservations still decides whether that member may view this reservation. Identity and permission to access a particular business record are different decisions.
The proposed split also reveals a design question worth taking back to a domain expert: Who may change the booking limit after reservations exist? If Workshop Planning can independently reduce it below the number already confirmed, the system can violate the no-overbooking rule without accepting a new reservation. A sound ownership arrangement would have Reservations validate any change to the limit it uses for admission. Workshop Planning can request that change or show its outcome, but must not bypass the rule. If organizers say that scheduling changes and capacity decisions are inseparable, that is evidence to revisit the proposed boundary—not a reason to conceal the conflict with a shared field.
Let invariants sharpen the boundary
An invariant is a condition that must remain true across valid changes of state. Here, the central one is: the number of confirmed places for a workshop never exceeds its approved booking limit. It matters at the moment a request is confirmed, including when two requests arrive together.
Ask three questions for each important rule:
- What operation could break it? Confirming a reservation, or changing the booking limit.
- What facts must be considered together to enforce it? The approved limit and places already committed.
- Who has authority to accept or reject that operation? One clearly owned admission rule, rather than independent decisions in Workshop Planning and Reservations.
This points to Reservations owning the admission decision. Workshop Planning can supply a workshop identifier and request a limit change, but a descriptive workshop model should not also confirm places. Conversely, Reservations need not own every scheduling detail merely because a reservation refers to a workshop.
The next video uses a different business example to make a narrower but important distinction: a bounded context sets the scope in which a model’s language and rules make sense; within that context, an aggregate can guard an invariant across related objects. You do not need to design the workshop aggregate yet.
Aggregate Design: Using Invariants as a Guide
Watch CodeOpinion’s Aggregate Design: Using Invariants as a Guide to see why an invariant can be a stronger grouping signal than simply noticing that two objects refer to each other.
In the shipment example, focus on why each stop’s valid state transitions are insufficient to guarantee that pickup precedes delivery. Then watch the entry point to see how the shipment guards the rule across stops. Apply the reasoning—not the shipment design—to confirmation and capacity in the workshop example.
This distinction prevents two opposite mistakes. Do not put every fact mentioning a workshop into one enormous model. But do not split a rule’s authoritative facts and updates across independent owners if the rule must hold at confirmation time. Displaying availability can tolerate a count that has changed since the page loaded; confirming a place cannot rely solely on that earlier display.
Discover boundaries collaboratively, then map the handoffs
Our two-context proposal came from a short brief. Real workflows contain exceptions, disputed terminology, and steps that developers may not know about. Strategic event storming is one way to expose them: people involved in the work place significant past-tense events in approximate chronological order, add the actors and commands that caused them, and discuss where language or responsibility changes.
DDD Eventstorm - Delivery Playbooks
Read the Delivery Playbooks’ DDD Eventstorm guidance for a practical way to discover candidate boundaries from a workflow, rather than starting with code packages.
Under “How to do it” → “Strategic Eventstorm,” read from the strategic goal. Later, in the numbered instructions, find steps 35, “Discover Bounded Contexts,” and 36, “Define Relationships Between Contexts (Context Mapping).” Read the boundary clues and the handoff guidance. Focus on changes in meaning and responsibility, not on the suggested sticky-note colors.
For our workflow, useful event names include Workshop Published, Reservation Requested, Reservation Confirmed, and Reservation Declined. Discussing those events may uncover an important correction: perhaps publishing a workshop requires its booking limit to be approved first. That discovery changes the handoff between planning and reservations. It does not automatically require both activities to use one model.
The diagram below shows a larger conference business divided into contexts. Notice that “Conferences,” “Seats,” and “Attendees” appear in more than one area. Repeated labels do not imply that every area must edit the same entity with the same rules.
In the workshop case, a small context map could record these handoffs in plain language:
- Workshop Planning to Reservations: identifies a published workshop and requests an approved booking limit. Reservations governs changes that could invalidate existing commitments.
- Accounts to Reservations: supplies the authenticated member’s identity. Reservations applies its own rule for who may see a reservation.
- Reservations to the workshop page: supplies availability information for display. Reservations makes the authoritative decision when a member requests confirmation.
This map states who owns a decision and what crosses the boundary. It does not yet specify an API, event, database arrangement, or deployment topology. When a handoff needs an instantaneous, shared decision to preserve a business rule, mark it as a hotspot and refine the boundaries or ownership with domain experts.
Conclusion
Find domain boundaries by following business work, listening for changes in terminology, and locating the decisions needed to preserve invariants. For the workshop feature, Workshop Planning and Reservations are plausible distinct models, but reservation admission must have one authoritative owner for committed places and its booking limit. Record unresolved handoffs rather than hiding them behind shared data.
Next, you’ll use these candidate boundaries alongside delivery and operational constraints to choose between a modular monolith and separately deployed services.