Context Mapper Examples

The insurance scenario is composed of several functional bounded contexts:

• Customer Management: A central context responsible for managing all customer data.
• Customer Self-Service Management: A web application context for customer logins and basic data updates (e.g., address changes).
• Policy Management: Manages customer contracts and policies. It uses a partnership with Risk Management and a shared kernel with Debt Collection.
• Debt Collection: Manages financial income (debts) derived from contracts and policies.
• Risk Management: Calculates risks that influence contracts and policies via a close relationship with Policy Management.
• Printing Context: An external system accessed via API by internal contexts to handle document printing (e.g., debts, policies).

This repository provides various DDD (Domain-Driven Design) Context Maps written in the ContextMapper DSL (CML). The examples range from business-oriented models to technical architectural models:

• Insurance Example: A classic DDD context map and a team map (illustrating bounded contexts implemented by specific teams) for a fictitious insurance company.
• Lakeside Mutual: A microservices-focused example demonstrating Microservice API Patterns (MAP), reverse-engineered from a real project.
• Context Mapper Example: A model of the Context Mapper tool and framework itself.
• DDD Cargo Sample: A model based on Eric Evans' DDD sample, split into three bounded contexts.
• Architectural Refactoring (AR) Examples: Examples showing input and output CML models for various architectural refactorings provided by the tool.

The Lakeside Mutual example demonstrates Context Mapper capabilities using a fictitious insurance project. It showcases two primary modeling approaches:

1. Reverse Engineering: The CML model was generated using the context-map-discovery library.
2. Event Storming: The model was enhanced to include a future 'claim processing' feature by modeling results from an Event Storming session.

You can find the complete CML model in LakesideMutual.cml.

The OOAD sample demonstrates a specific transformation pipeline:

1. Use Case Definition: A use case is defined in CML (e.g., claims-use-case.cml).
2. Domain Derivation: The use case is transformed to derive the Subdomain and Bounded Context.
3. Entity Generation: The derived model is used to generate a JDL file (e.g., claims-use-case-entities.jdl).
4. Application Generation: The JDL file is used to generate a microservice application.

In the Context Mapper DSL, you can specify how frequently an aggregate is expected to change using the likelihoodForChange attribute. This attribute is used by architectural refactorings like AR-4: Extract Aggregates by Volatility to group or isolate components.

Available values for likelihoodForChange:

• RARELY
• NORMAL
• OFTEN

Aggregate CustomerFrontend {
  likelihoodForChange = OFTEN
  // ...
}

This example demonstrates how to extend a reverse-engineered CML model by incorporating results from an Event Storming session. In this specific case, the model was extended to support a future 'claim processing' subdomain.

While a formal tutorial is pending, the example provides a visual reference of how Event Storming results (such as domain events and processes) can be mapped into the Context Mapper domain model.

The DDD Cargo sample is modeled using three bounded contexts to demonstrate specific relationship patterns in Context Mapper:

1. Core Application: The primary bounded context.
2. Voyage Scheduling: A separate bounded context that shares code with the core application, modeled using a Shared Kernel relationship.
3. Locations: A bounded context modeled as an Open Host Service (OHS) to provide location-related capabilities to other contexts.

This structure demonstrates how to model different interaction patterns between bounded contexts in CML.

CML allows you to model organizational teams and their relationships similarly to how you model bounded contexts. To create a Team Map, you must:

1. Change the type of a bounded context from SYSTEM, FEATURE, or APPLICATION to TEAM.
2. Set the type of the context map to ORGANIZATIONAL.
3. Use the realizes keyword to define which teams are responsible for specific systems, applications, or features.

When using the graphical Context Map generator, you can produce either unclustered or clustered illustrations to visualize the relations between development teams and system bounded contexts.

The Split Aggregate by Entities refactoring is a structural change applied at the Bounded Context level to optimize the granularity of aggregates.

Mental Model: In Domain-Driven Design (DDD), aggregates should group attributes that belong to the same identity and share a common lifecycle. If an aggregate grows too large and contains entities with different lifecycles, it creates unnecessary coupling. This refactoring automates the process of promoting entities to aggregate roots and moving them into distinct aggregate containers.

Relationship to other ARs:

• Inverse AR: AR-6: Merge Aggregates can be used to combine multiple aggregates back into one.