Domain detail

A template for enumerating and documenting each domain in your application, including bounded contexts, aggregates, entities, and their responsibilities.

For this activity, refer to chapter 2.4 Domain modeling as a guide. In the following section, enumerate each domain and bounded context. Details for each domain will be added as more use cases are layered in. Each section should describe the domain, its aggregates and entities, and the scope and purpose of the domain.

References

Context MapLinkDescription
Map namehttps://miro.com/app/board/… (or embed a /miro link)Scope of the map — which domains it covers, current as of YYYY-MM-DD, owner.
Map namehttps://…Description.

Domain Catalog

Using a collaborative, workshop style, guide the team in building your domain model. Work through your event maps, creating the following domain model artifacts as you go:

  1. Domain Descriptions: 2-5 sentences describing each domain with clear business language. Remember to ground the language in your agreed-upon ubiquitous language.
  2. Bounded Contexts: Itemize bounded contexts for each domain (this will probably not be exhaustive, since your contexts will continue to evolve).
  3. Define Responsibilities: Each context must include a list of responsibilities that are independent to that context, and not overlapping any other context.

Domain: LOAN

AggregatesLoan Account, Installation Plan, Payment Ledger
Bounded Context DescriptionThe Loan Bounded Context is responsible for managing the borrower’s loan information such as autopay enrollment, current balance, etc. It is also responsible for managing all borrower’s installment options based on payment terms (6 months, 12 months, etc.) and order price. It keeps track of all borrower’s installment payments to MyBank.

Aggregates

Aggregates Description
AggregateResponsibility
Loan Account
  • Contains information on loan details such as the loan term, loan amount, due date, payment date, etc.
Installment Plan
  • Contains information related to 3 different installment options
Payment Ledger
  • Tracks loan payment transaction details
  • Provide loan audit history

Outstanding questions

  • How should promotional rates that change mid-term be reflected in the Installment Plan aggregate?
  • What is the policy for early payoff — does Payment Ledger need a separate event, or is it folded into the existing payment events?

Next steps

  • Validate Payment Ledger’s audit-history retention with the compliance team.
  • Confirm Loan Account ↔ Installment Plan boundary with the finance lead before formalizing the context map.

Domain: DOMAIN NAME

AggregatesItemize aggregate(s)
Bounded Context DescriptionDetailed bounded context description

Aggregates

Aggregates Description
AggregateResponsibility
Aggregate name
  • Primary responsibility of the aggregate, expressed in ubiquitous language.
  • Secondary responsibility or invariant the aggregate enforces.
Aggregate name
  • Responsibility of the next aggregate.

Outstanding questions

  • Open question that the team needs to resolve before formalizing the model.
  • Cross-context concern that may affect adjacent domains.

Next steps

  • Concrete next action — e.g., validate boundaries with the business owner.
  • Follow-up workshop, decision, or artifact to produce.