### Merge Aggregates: Input CML Example

Source: https://github.com/contextmapper/context-mapper-examples/blob/master/src/main/cml/architectural-refactorings/AR-06-Merge-Aggregates/README.md

This CML snippet represents the input state for the 'Merge Aggregates' refactoring. It shows a bounded context 'CustomerManagementContext' with two distinct aggregates: 'Customers' and 'Addresses'. The 'Customers' aggregate contains a 'Customer' entity and a 'SocialInsuranceNumber' value object, while the 'Addresses' aggregate contains an 'Address' entity. This serves as the starting point for the merging operation.

```CML
/* With a right-click on the 'Customers' aggregate (or on the 'Addresses' aggregate, as you wish) 
 * you can execute the 'Merge Aggregates' refactoring. A dialog will show up and ask you with 
 * which other aggregate you want to merge. Choose the other aggregate and the refactoring will merge them. 
 */
BoundedContext CustomerManagementContext implements CustomerManagementDomain {
  type = FEATURE
  domainVisionStatement = "The customer management context is responsible for managing all the data of the insurance companies customers."
  implementationTechnology = "Java, JEE Application"
  responsibilities = "Customers, Addresses"
  
  Aggregate Customers {
    Entity Customer {
      aggregateRoot
      - SocialInsuranceNumber sin
      String firstname
      String lastname
      - List<Address> addresses
    }
    ValueObject SocialInsuranceNumber {
      String sin key
    }
  }
  Aggregate Addresses {
    Entity Address {
      String street
      int postalCode
      String city
    }
  }
}
```

--------------------------------

### Split Bounded Context by Features Example (CML)

Source: https://github.com/contextmapper/context-mapper-examples/blob/master/src/main/cml/architectural-refactorings/AR-02-Split-Bounded-Context-by-Features/README.md

An example demonstrating the 'Split Bounded Context by Features' architectural refactoring in Context Mapper Language (CML). It shows an input bounded context with aggregates used by different use cases, illustrating how the refactoring would split it into multiple contexts.

```CML
/* With a right-click on the 'PolicyManagementContext' bounded context you can execute the 'Split Bounded Context by Features' refactoring. 
 * It will split the existing bounded context and group the two aggregates of the 'CreateOffer4Customer' use case together. The 'Contract' 
 * aggregate used by the 'UpdateContract' use case will be separated. 
 */
BoundedContext PolicyManagementContext implements PolicyManagementDomain {
  type = FEATURE
  domainVisionStatement = "This bounded context manages the contracts and policies of the customers."
  responsibilities = "Offers, Contracts, Policies"
  implementationTechnology = "Java, Spring App"
  
  Aggregate Offers {
    useCases = CreateOffer4Customer
    
    Entity Offer {
      aggregateRoot
      
      int offerId
      - Customer client
      - List<Product> products
      BigDecimal price
    }
  }
  Aggregate Products {
    useCases = CreateOffer4Customer
    
    Entity Product {
      aggregateRoot
      
      - ProductId identifier
      String productName
    }
    ValueObject ProductId {
      int productId key
    }
  }
  Aggregate Contract {
    useCases = UpdateContract
    
    Entity Contract {
      aggregateRoot
      
      - ContractId identifier
      - Customer client
      - List<Product> products
    }
    ValueObject ContractId {
      int contractId key
    }
    
    Entity Policy {
      int policyNr
      - Contract contract
      BigDecimal price
    }
  }
}
```

--------------------------------

### Split Aggregate by Entities: Input Example (CML)

Source: https://github.com/contextmapper/context-mapper-examples/blob/master/src/main/cml/architectural-refactorings/AR-01-Split-Aggregate-by-Entities/README.md

This CML snippet demonstrates the input structure for the 'Split Aggregate by Entities' refactoring. It shows a bounded context with a single aggregate named 'Customers' containing two entities: 'Customer' and 'Address'. The 'Customer' entity has a reference to 'Address'.

```CML
BoundedContext CustomerManagementContext {
  type = FEATURE
  domainVisionStatement = "The customer management context is responsible for managing all the data of the insurance companies customers."
  implementationTechnology = "Java, JEE Application"
  responsibilities = "Customers, Addresses"

  /* With a Right-Click on the 'Customers' aggregate you can call the 'Split Aggregate by Entities' refactoring in the 
   * 'Context Mapper: Refactor' context menu. The refactoring will create a new aggregate and move one of the two entities 
   * to the new aggregate (see the result in the 'split-aggregate-by-entities-output-example.cml' file).
   */  
  Aggregate Customers {
    Entity Customer {
      aggregateRoot
      
      String firstname
      String lastname
      - List<Address> addresses
    }
    Entity Address {
      String street
      int postalCode
      String city
    }
  }
}
```

--------------------------------

### Define Domains and Subdomains (CML)

Source: https://context7.com/contextmapper/context-mapper-examples/llms.txt

Classifies different parts of a business problem space using CML. This example defines the 'InsuranceDomain' and its subdomains, categorizing them as Core, Supporting, or Generic Subdomains, each with a descriptive domain vision statement.

```cml
Domain InsuranceDomain {
    Subdomain CustomerManagementDomain {
        type = CORE_DOMAIN
        domainVisionStatement = "Subdomain managing everything customer-related."
    }

    Subdomain PolicyManagementDomain {
        type = CORE_DOMAIN
        domainVisionStatement = "Subdomain managing contracts and policies."
    }

    Subdomain PrintingDomain {
        type = SUPPORTING_DOMAIN
        domainVisionStatement = "Service to solve printing for documents."
    }

    Subdomain RiskManagementDomain {
        type = GENERIC_SUBDOMAIN
        domainVisionStatement = "Subdomain for risk management calculations."
    }

    Subdomain DebtsDomain {
        type = GENERIC_SUBDOMAIN
        domainVisionStatement = "Subdomain for debts and dunning."
    }
}
```

--------------------------------

### Output: Merged Bounded Context Example (CML)

Source: https://github.com/contextmapper/context-mapper-examples/blob/master/src/main/cml/architectural-refactorings/AR-09-Suspend-Partnership/README.md

This CML snippet shows the output after applying the 'Suspend Partnership' refactoring with the 'Merge the two Bounded Contexts' mode. The original Partnership relationship is removed, and the two Bounded Contexts are merged into one.

```CML
ContextMap InsuranceContextMap {
  type = SYSTEM_LANDSCAPE
  state = TO_BE
  
  contains RiskManagementContext
  
  /* Since the AR merged the two Bounded Context, the relationship has been removed. */
}

/* The merged Bounded Context contains all Aggregates of both contexts now.  */
BoundedContext RiskManagementContext {
  /* ... */
}

```

--------------------------------

### Input Partnership Relationship Example (CML)

Source: https://github.com/contextmapper/context-mapper-examples/blob/master/src/main/cml/architectural-refactorings/AR-09-Suspend-Partnership/README.md

This CML snippet defines two Bounded Contexts, PolicyManagementContext and RiskManagementContext, in a Partnership relationship within the InsuranceContextMap. It serves as the input for the 'Suspend Partnership' refactoring.

```CML
ContextMap InsuranceContextMap {
  type = SYSTEM_LANDSCAPE
  state = TO_BE
  
  contains PolicyManagementContext
  contains RiskManagementContext

  /* With a right-click on the Partnership relationship ([P]<->[P]) you can execute the 'Suspend Partnership' 
   * refactoring. On a dialog you can then choose between three modes how to suspend the partnership:
   * a) Merge the two Bounded Contexts (executes 'AR-7 Merge Bounded Contexts').
   * b) Extract a new Bounded Context for commonalities and establish upstream-downstream relationships between
   *    the new and the existing two Bounded Contexts.
   * c) Simply replace the Partnership relationship with an upstream-downstream relationship (in this case
   *    you have to choose which Bounded Context becomes upstream context).
   */
  RiskManagementContext [P]<->[P] PolicyManagementContext {
    implementationTechnology = "RabbitMQ"
  }

}

BoundedContext PolicyManagementContext {
  /* ... */
}

BoundedContext RiskManagementContext {
  /* ... */
}

```

--------------------------------

### Document Bounded Context with Canvas in CML

Source: https://context7.com/contextmapper/context-mapper-examples/llms.txt

Supports the Bounded Context Canvas pattern for documenting strategic context information. This CML code illustrates how to define business model classification, evolution stage, and other metadata for a bounded context.

```cml
BoundedContext CustomerManagementContext implements CustomerManagementDomain {
    /* Business model classification */
    businessModel = "ENGAGEMENT"

    /* Evolution stage: GENESIS, CUSTOM_BUILT, PRODUCT, or COMMODITY */
    evolution = CUSTOM_BUILT

    /* Context metadata */
    type = APPLICATION
    domainVisionStatement = "Web application for customer self-service"
    responsibilities = "AddressChange"
    implementationTechnology = "PHP Web Application"
}
```

--------------------------------

### Model Domain Events and Commands in CML

Source: https://context7.com/contextmapper/context-mapper-examples/llms.txt

This CML snippet demonstrates modeling Event Storming artifacts within a Bounded Context. It includes defining aggregates, entities, enums, domain events, commands, and services, showcasing how to capture business workflows and state transitions.

```cml
BoundedContext ClaimsManagement implements ClaimsManagement {
    type FEATURE
    domainVisionStatement "Manages the processing of insurance claims"

    Aggregate Claims {
        Entity Claim {
            aggregateRoot
            long claimId
            - CustomerId customer
            String description
            boolean isComplete
            - ClaimState claimState
        }

        enum ClaimState {
            OPEN, REJECTED, ACCEPTED
        }

        /* Domain Events represent things that happened */
        abstract DomainEvent AbstractClaimEvent {
            Date timestamp
            - Claim claim
        }

        DomainEvent ClaimRegistered extends @AbstractClaimEvent
        DomainEvent AssessmentPerformed extends @AbstractClaimEvent
        DomainEvent ClaimAccepted extends @AbstractClaimEvent
        DomainEvent ClaimRejected extends @AbstractClaimEvent

        /* Commands represent user/system intentions */
        abstract CommandEvent AbstractClaimCommand {
            - Claim claim
        }

        "role: Administrator"
        CommandEvent CheckClaimDocumentation extends @AbstractClaimCommand

        "role: Claims department"
        CommandEvent CheckInsurance extends @AbstractClaimCommand {
            - Set<PolicyId> policies
        }

        CommandEvent AcceptClaim extends @AbstractClaimCommand
        CommandEvent RejectClaim extends @AbstractClaimCommand

        /* Service implementing command handlers */
        Service ClaimService {
            @ClaimRegistered checkDocumentation(@CheckClaimDocumentation cmd);
            @AssessmentPerformed checkInsurance(@CheckInsurance cmd);
            @ClaimAccepted acceptClaim(@AcceptClaim cmd);
            @ClaimRejected rejectClaim(@RejectClaim cmd);
        }
    }
}
```

--------------------------------

### Split Aggregate by Entities: Output Example (CML)

Source: https://github.com/contextmapper/context-mapper-examples/blob/master/src/main/cml/architectural-refactorings/AR-01-Split-Aggregate-by-Entities/README.md

This CML snippet illustrates the output after applying the 'Split Aggregate by Entities' refactoring. The original aggregate 'Customers' is split, resulting in two aggregates. One aggregate, 'Customers', now contains only the 'Address' entity as its root. A new aggregate, 'NewAggregate1', is created containing the 'Customer' entity as its root. Note that the names of the new aggregates might require manual renaming.

```CML
BoundedContext CustomerManagementContext {
  domainVisionStatement = "The customer management context is responsible for managing all the data of the insurance companies customers."
  responsibilities = "Customers, Addresses" implementationTechnology = "Java, JEE Application"
  Aggregate Customers {
    Entity Address {
      aggregateRoot
      
      String street
      int postalCode
      String city
    }
  }
  /* The newly created aggregate after applying 'Split Aggregate by Entities' on the aggregate in the input file 
   * 'example-input.cml'. 
   * 
   * Note that the refactoring does not produce meaningful aggregate names. You can use the 'Rename Element' 
   * refactoring (SHIFT-ALT-R) to rename the new aggregate.
   */
  Aggregate NewAggregate1 {
    Entity Customer {
      aggregateRoot
      
      String firstname
      String lastname
      - List<Address> addresses
    }
  }
}
```

--------------------------------

### Define Application Flow with State Transitions in CML

Source: https://context7.com/contextmapper/context-mapper-examples/llms.txt

This snippet defines an application flow using CML, illustrating how commands trigger state transitions and emit events. It shows operations reacting to events and potentially branching to different aggregate lifecycle states. Dependencies include CML syntax for commands, events, operations, and aggregate states.

```cml
BoundedContext InsuranceQuotes {
    Application {
        Command SubmitRequest

        Flow QuoteRequestFlow {
            /* Command triggers state transition and emits event */
            command SubmitRequest delegates to QuoteRequest[-> SUBMITTED]
                emits event RequestSubmitted

            /* Event triggers operation */
            event RequestSubmitted + RequestSubmitted triggers operation checkRequest

            /* Operation can branch to multiple states */
            operation checkRequest delegates to QuoteRequest[SUBMITTED -> RECEIVED X REJECTED]
                emits event QuoteReceived X RequestRejected

            event QuoteReceived triggers operation receiveAndCheckQuote

            operation receiveAndCheckQuote
                delegates to QuoteRequest[RECEIVED -> REJECTED X ACCEPTED X EXPIRED]
                emits event QuoteRejected X QuoteAccepted X QuoteExpired

            event QuoteAccepted triggers operation accept

            operation accept delegates to QuoteRequest[ACCEPTED -> POLICY_CREATED X EXPIRED]
                emits event PolicyCreated X QuoteExpired
        }
    }

    Aggregate QuoteRequest {
        Entity Request {
            aggregateRoot
        }

        DomainEvent RequestSubmitted
        DomainEvent QuoteReceived
        DomainEvent RequestRejected
        DomainEvent QuoteAccepted
        DomainEvent QuoteExpired
        DomainEvent PolicyCreated

        Service QuoteRequestService {
            void checkRequest(@Request request);
            void receiveAndCheckQuote(@Request request);
            void accept(@Request request);
        }

        enum RequestState {
            aggregateLifecycle
            SUBMITTED, RECEIVED, REJECTED, ACCEPTED, EXPIRED, POLICY_CREATED
        }
    }
}
```

--------------------------------

### Define Bounded Context with Aggregates (CML)

Source: https://context7.com/contextmapper/context-mapper-examples/llms.txt

Models the 'PolicyManagementContext' Bounded Context using CML, detailing its domain vision, responsibilities, and implementation technology. It includes Aggregates like 'Offers', 'Products', and 'Contract', each containing Entities and Value Objects with their attributes and relationships.

```cml
BoundedContext PolicyManagementContext implements PolicyManagementDomain {
    type = FEATURE
    domainVisionStatement = "This bounded context manages contracts and policies."
    responsibilities = "Offers, Contracts, Policies"
    implementationTechnology = "Java, Spring App"

    Aggregate Offers {
        owner ContractsTeam

        Entity Offer {
            aggregateRoot

            int offerId
            - Customer client
            - List<Product> products
            BigDecimal price
        }
    }

    Aggregate Products {
        owner ProductsTeam

        Entity Product {
            aggregateRoot

            - ProductId identifier
            String productName
        }

        ValueObject ProductId {
            int productId key
        }
    }

    Aggregate Contract {
        owner ContractsTeam

        Entity Contract {
            aggregateRoot

            - ContractId identifier
            - Customer client
            - List<Product> products
        }

        ValueObject ContractId {
            int contractId key
        }

        Entity Policy {
            int policyNr
            - Contract contract
            BigDecimal price
        }
    }
}
```

--------------------------------

### Merge Aggregates: Output CML Example

Source: https://github.com/contextmapper/context-mapper-examples/blob/master/src/main/cml/architectural-refactorings/AR-06-Merge-Aggregates/README.md

This CML snippet illustrates the output of the 'Merge Aggregates' refactoring. After applying the AR to merge the 'Customers' and 'Addresses' aggregates, the 'Addresses' aggregate's contents (the 'Address' entity) are incorporated into the 'Customers' aggregate. The 'Addresses' aggregate is effectively removed, resulting in a single, consolidated aggregate within the 'CustomerManagementContext'.

```CML
/* 
 * The resulting bounded context after applying 'Merge Aggregates' to the file 'example-input.cml'.
 * The 'Addresses' aggregate has been merged into the 'Customers' aggregate. 
 */
BoundedContext CustomerManagementContext implements CustomerManagementDomain {
  domainVisionStatement = "The customer management context is responsible for managing all the data of the insurance companies customers."
  responsibilities = "Customers, Addresses" 
  implementationTechnology = "Java, JEE Application"
  Aggregate Customers {
    Entity Customer {
      aggregateRoot
      - SocialInsuranceNumber sin
      String firstname
      String lastname
      - List<Address> addresses
    }
    ValueObject SocialInsuranceNumber {
      String sin key
    }
    Entity Address {
      String street
      int postalCode
      String city
    }
  }
}
```

--------------------------------

### Extract Aggregates by Volatility - Input Example (CML)

Source: https://github.com/contextmapper/context-mapper-examples/blob/master/src/main/cml/architectural-refactorings/AR-04-Extract-Aggregates-by-Volatility/README.md

This CML snippet demonstrates the input structure for the 'Extract Aggregates by Volatility' refactoring. It shows a bounded context with two aggregates, 'CustomerFrontend' and 'Acounts', where 'CustomerFrontend' has a likelihoodForChange set to OFTEN.

```cml
/* With a right-click on the 'CustomerSelfServiceContext' bounded context you can execute the 'Extract Aggregates by Volatility' 
 * refactoring. If you choose the volatility 'OFTEN', it will extract the volatile 'CustomerFrontend' aggregate and create a new bounded context for it. 
 */
BoundedContext CustomerSelfServiceContext implements CustomerManagementDomain {
  type = APPLICATION
  domainVisionStatement = "This context represents a web application which allows the customer to login and change basic data records like the address."
  responsibilities = "AddressChange"
  implementationTechnology = "PHP Web Application"
  
  Aggregate CustomerFrontend {
    likelihoodForChange = OFTEN
    
    DomainEvent CustomerAddressChange {
      aggregateRoot
      
      - UserAccount issuer
      - Address changedAddress
    }
  }
  Aggregate Acounts {
    Entity UserAccount {
      aggregateRoot
      
      String username
      - Customer accountCustomer
    }
  }
}
```

--------------------------------

### Define Teams and Bounded Context Ownership in CML

Source: https://context7.com/contextmapper/context-mapper-examples/llms.txt

Defines organizational structures by associating teams with the bounded contexts they implement. This CML code snippet demonstrates how to declare teams and assign ownership of aggregates within bounded contexts.

```cml
/* Team definitions */
BoundedContext ContractsTeam { type TEAM }
BoundedContext ProductsTeam { type TEAM }
BoundedContext FinancesTeam { type TEAM }
BoundedContext RisksTeam { type TEAM }

/* Bounded Context with team ownership */
BoundedContext PolicyManagementContext {
    Aggregate Offers {
        owner ContractsTeam

        Entity Offer {
            aggregateRoot
            int offerId
        }
    }

    Aggregate Products {
        owner ProductsTeam

        Entity Product {
            aggregateRoot
            String productName
        }
    }
}

BoundedContext DebtCollection {
    Aggregate Debts {
        owner = FinancesTeam

        Entity Debt {
            aggregateRoot
            int debtNr
        }
    }
}
```

--------------------------------

### Model CQRS Pattern with Separate Read/Write Services in CML

Source: https://context7.com/contextmapper/context-mapper-examples/llms.txt

This CML snippet demonstrates the Command Query Responsibility Segregation (CQRS) pattern. It defines a 'CustomerCore' bounded context with separate aggregates for command (write) and query (read) operations, including infrastructure for event sourcing and read storage. Dependencies include CML syntax for aggregates, entities, services, DTOs, and repositories.

```cml
BoundedContext CustomerCore {
    /* Traditional service with both reads and writes */
    Aggregate CustomerAggregate {
        Entity Customer {
            aggregateRoot
            - CustomerId customerId
            String firstName
            String lastName
            - List<Address> addresses
        }

        /* Command service for write operations */
        Service CustomerCommandService {
            @CustomerId createCustomer(@Customer customer);
            void updateCustomer(@Customer customer);
            boolean deleteCustomer(@CustomerId customer);
        }
    }

    /* Separate read model for queries */
    Aggregate CustomerReadModel {
        DataTransferObject CustomerDTO {
            String firstName
            String lastName
        }

        /* Query service for read operations */
        Service CustomerQueryService {
            @CustomerDTO findCustomerById(@CustomerId customerId);
            List<@CustomerDTO> findCustomersByName(String name);
        }
    }

    /* Infrastructure for event sourcing */
    Aggregate CQRS_CommandInfrastructure {
        Service CommandDAO {
            @EventSequence storeAndForwardEvents() publish to EventHandlerChannel;
        }
        Entity EventStore {
            aggregateRoot
            Repository EventStoreRepository {}
        }
    }

    Aggregate CQRS_QueryInfrastructure {
        Entity ReadStorage {
            aggregateRoot
            Repository ReadStorageRepository {
                subscribe to EventHandlerChannel
            }
        }
    }
}
```

--------------------------------

### Input Context Map with Shared Kernel Relationship

Source: https://github.com/contextmapper/context-mapper-examples/blob/master/src/main/cml/architectural-refactorings/AR-08-Extract-Shared-Kernel/README.md

This CML snippet represents the initial state of a Context Map where two Bounded Contexts, 'PolicyManagementContext' and 'DebtCollection', share a 'Shared Kernel' relationship. This indicates a close coupling and shared domain model parts between them.

```CML
ContextMap InsuranceContextMap {
  type = SYSTEM_LANDSCAPE
  state = TO_BE
  
  contains PolicyManagementContext
  contains DebtCollection

  /* With a right-click on the Shared Kernel relationship ([SK]<->[SK]) you can execute the 'Extract Shared Kernel' 
   * refactoring. It will create a new Bounded Context for the shared code (content of new Bounded Context has to
   * specified manually). Two new upstream-downstream relationships will be created to connect the existing Bounded
   * Contexts with the new one. After applying this AR, you can use the 'Rename Element' refactoring to change
   * the generated name of the new Bounded Context. 
   */
  PolicyManagementContext [SK]<->[SK] DebtCollection {
    implementationTechnology = "Shared Java Library, Communication over RESTful HTTP"
  }

}

BoundedContext PolicyManagementContext {
  /* ... */
}

BoundedContext DebtCollection {
  /* ... */
}

```

--------------------------------

### Split Bounded Context by Owner: CML Input Example

Source: https://github.com/contextmapper/context-mapper-examples/blob/master/src/main/cml/architectural-refactorings/AR-03-Split-Bounded-Context-by-Owner/README.md

This CML snippet demonstrates the input for the 'Split Bounded Context by Owner' refactoring. It shows a single bounded context 'CustomerSelfServiceContext' containing two aggregates, 'CustomerFrontend' and 'Acounts', owned by different teams ('CustomerFrontendTeam' and 'CustomerBackendTeam').

```cml
/* With a right-click on the 'CustomerSelfServiceContext' bounded context you can execute the 'Split Bounded Context by Owners' refactoring. 
 * It will split the existing bounded context according to the two owning teams 'CustomerBackendTeam' and 'CustomerFrontendTeam'.
 */
BoundedContext CustomerSelfServiceContext implements CustomerManagementDomain {
  type = APPLICATION
  domainVisionStatement = "This context represents a web application which allows the customer to login and change basic data records like the address."
  responsibilities = "AddressChange"
  implementationTechnology = "PHP Web Application"
  
  Aggregate CustomerFrontend {
    owner = CustomerFrontendTeam
    
    DomainEvent CustomerAddressChange {
      aggregateRoot
      
      - UserAccount issuer
      - Address changedAddress
    }
  }
  Aggregate Acounts {
    owner = CustomerBackendTeam
    
    Entity UserAccount {
      aggregateRoot
      
      String username
      - Customer accountCustomer
    }
  }
}
```

--------------------------------

### Merge Bounded Contexts Example - Input CML

Source: https://github.com/contextmapper/context-mapper-examples/blob/master/src/main/cml/architectural-refactorings/AR-07-Merge-Bounded-Contexts/README.md

This CML snippet demonstrates the input structure for the 'Merge Bounded Contexts' architectural refactoring. It defines two distinct bounded contexts, 'CustomerManagementContext' and 'CustomerSelfServiceContext', each with their own aggregates and responsibilities.

```cml
/* With a right-click on the 'CustomerManagementContext' (or one of the other contexts, as you wish) 
 * bounded context you can execute the 'Merge Bounded Contexts' refactoring. A dialog will show up and ask you with 
 * which other bounded context you want to merge. Choose a second bounded context and the refactoring will merge them. 
 */
BoundedContext CustomerManagementContext implements CustomerManagementDomain {
  type = FEATURE
  domainVisionStatement = "The customer management context is responsible for managing all the data of the insurance companies customers."
  implementationTechnology = "Java, JEE Application"
  responsibilities = "Customers, Addresses"
  
  Aggregate Customers {
    Entity Customer {
      aggregateRoot
      
      - SocialInsuranceNumber sin
      String firstname
      String lastname
      - List<Address> addresses
    }
    Entity Address {
      String street
      int postalCode
      String city
    }
    ValueObject SocialInsuranceNumber {
      String sin key
    }
  }
}

BoundedContext CustomerSelfServiceContext implements CustomerManagementDomain {
  type = APPLICATION
  domainVisionStatement = "This context represents a web application which allows the customer to login and change basic data records like the address."
  responsibilities = "AddressChange"
  implementationTechnology = "PHP Web Application"
  
  Aggregate CustomerFrontend {
    DomainEvent CustomerAddressChange {
      aggregateRoot
      
      - UserAccount issuer
      - Address changedAddress
    }
  }
  Aggregate Acounts {
    Entity UserAccount {
      aggregateRoot
      
      String username
      - Customer accountCustomer
    }
  }
}
```

--------------------------------

### Extract Bounded Context for Commonalities with Upstream-Downstream Relationships

Source: https://github.com/contextmapper/context-mapper-examples/blob/master/src/main/cml/architectural-refactorings/AR-09-Suspend-Partnership/README.md

Applies the 'Suspend Partnership' refactoring to extract a new Bounded Context that represents commonalities. It establishes new upstream-downstream relationships between this new context and the original ones. This mode is useful for consolidating shared responsibilities.

```Context Mapper
ContextMap InsuranceContextMap {
  type = SYSTEM_LANDSCAPE
  state = TO_BE
  
  contains PolicyManagementContext
  contains RiskManagementContext
  contains RiskManagementContext_PolicyManagementContext_Partnership

  /* New upstream-downstream relationships between the new and the existing two Bounded Contexts: */

  RiskManagementContext_PolicyManagementContext_Partnership [ U ] -> [ D ] RiskManagementContext

  RiskManagementContext_PolicyManagementContext_Partnership [ U ] -> [ D ] PolicyManagementContext

}

BoundedContext PolicyManagementContext {
  /* ... */
}

BoundedContext RiskManagementContext {
  /* ... */
}

/* The new Bounded Context created by the 'Suspend Partnership' refactoring:
 * (can be renamed with the 'Rename Element' refactoring)
 */
BoundedContext RiskManagementContext_PolicyManagementContext_Partnership

```

--------------------------------

### Model Use Case Interactions in CML

Source: https://context7.com/contextmapper/context-mapper-examples/llms.txt

This CML snippet models a use case, 'Get_paid_for_car_accident', detailing actor interactions and system behavior. It specifies the sequence of actions, involved entities, and their attributes. This can be used to drive domain model derivation.

```cml
/* Use Case from Alistair Cockburn's "Writing Effective Use Cases" */
UseCase Get_paid_for_car_accident {
    actor "Claimant"

    interactions
        "submit" a "Claim" with its "date", "amountClaimed", "description" for a "Policy",
        "verifyExistanceOf" "Policy" with its "startDate", "endDate" for a "Contract",
        "assign" an "Agent" with its "personalID", "firstName", "lastName" for "Claim",
        "verify" "Policy" for a "Contract",
        "pay" "Claimant" with its "firstName", "lastName",
        "close" "Claim" for "Claimant"

    benefit "A claimant submits a claim and gets paid from the insurance company."
    scope "Insurance company"
    level "Summary"
}
```

--------------------------------

### Define DDD Relationship Patterns in CML

Source: https://context7.com/contextmapper/context-mapper-examples/llms.txt

This snippet illustrates how to define various DDD strategic relationship patterns (Conformist, ACL, OHS, Published Language) between bounded contexts using Context Mapper Language (CML). It shows the syntax for specifying exposed aggregates and relationship types.

```cml
ContextMap LakesideMutual {
    contains CustomerCore, CustomerManagement, CustomerSelfService
    contains PolicyManagement, ClaimsManagement

    /* Open Host Service with Published Language - upstream exposes API */
    CustomerCore [OHS, PL]-> CustomerManagement {
        exposedAggregates cities, CustomerCore_customers
    }

    /* Conformist - downstream conforms to upstream model */
    CustomerCore [OHS, PL]->[CF] CustomerSelfService {
        exposedAggregates cities, CustomerCore_customers
    }

    /* Anti-Corruption Layer - downstream translates upstream model */
    CustomerCore [OHS, PL]->[ACL] PolicyManagement {
        exposedAggregates cities, CustomerCore_customers
    }

    /* Simple upstream-downstream without patterns */
    PolicyManagement -> CustomerSelfService {
        exposedAggregates insurance_quote_requests, customers, policies
    }
}
```

--------------------------------

### Context Map Refactoring: Shared Kernel to Partnership (CML)

Source: https://github.com/contextmapper/context-mapper-examples/blob/master/src/main/cml/architectural-refactorings/AR-10-Change-Shared-Kernel-To-Partnership/README.md

This snippet demonstrates the transformation of a Shared Kernel relationship to a Partnership relationship within a Context Map using Context Mapping Language (CML). It highlights the input and output states of the refactoring.

```cml
ContextMap InsuranceContextMap {
  type = SYSTEM_LANDSCAPE
  state = TO_BE
  contains PolicyManagementContext
  contains DebtCollection

  /* With a right-click on the Shared Kernel relationship ([SK]<->[SK]) you can execute the 'Change to Partnership' 
   * refactoring. It will replace the Shared Kernel relationship below with a corresponding Partnership relationship
   * between the two Bounded Contexts.
   */
  PolicyManagementContext [SK]<->[SK] DebtCollection

}

BoundedContext PolicyManagementContext

BoundedContext DebtCollection

```

```cml
ContextMap InsuranceContextMap {
  type = SYSTEM_LANDSCAPE
  state = TO_BE
  contains PolicyManagementContext
  contains DebtCollection

  /* The new Partnership relationship after applying the 'Change Shared Kernel to Partnership' refactoring to the 
   * Shared Kernel within the 'example-input.cml' file:
   */
  PolicyManagementContext [P] <-> [P] DebtCollection

}

BoundedContext PolicyManagementContext

BoundedContext DebtCollection

```

--------------------------------

### Replace Partnership with Upstream-Downstream Relationship

Source: https://github.com/contextmapper/context-mapper-examples/blob/master/src/main/cml/architectural-refactorings/AR-09-Suspend-Partnership/README.md

Applies the 'Suspend Partnership' refactoring to directly replace an existing partnership relationship with a new upstream-downstream relationship. This mode simplifies the context map by removing the partnership concept and explicitly defining the flow of information or dependency.

```Context Mapper
ContextMap InsuranceContextMap {
  type = SYSTEM_LANDSCAPE
  state = TO_BE
  
  contains PolicyManagementContext
  contains RiskManagementContext

  /* The new upstream-downstream relationship replacing the original Partnership relationship: */
  
  PolicyManagementContext [ U ] -> [ D ] RiskManagementContext

}

BoundedContext PolicyManagementContext {
  /* ... */
}

BoundedContext RiskManagementContext {
  /* ... */
}

```

--------------------------------

### Split Bounded Context by Owner: CML Output Example

Source: https://github.com/contextmapper/context-mapper-examples/blob/master/src/main/cml/architectural-refactorings/AR-03-Split-Bounded-Context-by-Owner/README.md

This CML snippet illustrates the output after applying the 'Split Bounded Context by Owner' refactoring. The original bounded context is split into two: one containing aggregates owned by 'CustomerFrontendTeam' and another for aggregates owned by 'CustomerBackendTeam'. The refactoring creates new bounded contexts, and manual adjustments for naming and ordering might be necessary.

```cml
BoundedContext CustomerSelfServiceContext implements CustomerManagementDomain {
  domainVisionStatement = "This context represents a web application which allows the customer to login and change basic data records like the address."
  type = APPLICATION
  responsibilities = "AddressChange"
  implementationTechnology = "PHP Web Application"
  
  Aggregate CustomerFrontend {
    owner = CustomerFrontendTeam
    
    DomainEvent CustomerAddressChange {
      aggregateRoot
      
      - UserAccount issuer
      - Address changedAddress
    }
  }
}

/**
 * The new bounded context created by the 'Split Bounded Context by Owners' refactoring applied to 'example-input.cml'.
 * 
 * Note that the refactoring does not produce meaningful bounded context names. You can use the 'Rename Element' refactoring (SHIFT-ALT-R) 
 * to rename the new aggregate. 
 * 
 * The automated refactorings add newly created bounded contexts at the end of the 'bounded context' block, which might not always be the
 * desired order. You may change the order after the refactoring manually.
 */
BoundedContext NewBoundedContext1 {
  Aggregate Acounts {
    owner = CustomerBackendTeam
    
    Entity UserAccount {
      aggregateRoot
      
      String username
      - Customer accountCustomer
    }
  }
}
```

--------------------------------

### Change Partnership to Shared Kernel Relationship (CML)

Source: https://github.com/contextmapper/context-mapper-examples/blob/master/src/main/cml/architectural-refactorings/AR-11-Change-Partnership-To-Shared-Kernel/README.md

This code snippet demonstrates the transformation of a Partnership relationship ([P]<->[P]) to a Shared Kernel relationship ([SK]<->[SK]) within a Context Map using Context Mapping Language (CML). The refactoring is applied to illustrate the change in relationship type without altering the underlying bounded contexts.

```cml
ContextMap InsuranceContextMap {
  type = SYSTEM_LANDSCAPE
  state = TO_BE
  contains PolicyManagementContext
  contains RiskManagementContext

  /* With a right-click on the Partnership relationship ([P]<->[P]) you can execute the 'Change to Shared Kernel' 
   * refactoring. It will replace the Partnership relationship below with a corresponding Shared Kernel relationship
   * between the two Bounded Contexts.
   */
  RiskManagementContext [P]<->[P] PolicyManagementContext

}

BoundedContext PolicyManagementContext

BoundedContext RiskManagementContext
```

```cml
ContextMap InsuranceContextMap {
  type = SYSTEM_LANDSCAPE
  state = TO_BE
  contains PolicyManagementContext
  contains RiskManagementContext

  /* The new Shared Kernel relationship after applying the 'Change Partnership to Shared Kernel' refactoring to the 
   * Partnership within the 'example-input.cml' file:
   */
  RiskManagementContext [SK] <-> [SK] PolicyManagementContext

}

BoundedContext PolicyManagementContext

BoundedContext RiskManagementContext
```

--------------------------------

### Define Context Map for Insurance System (CML)

Source: https://context7.com/contextmapper/context-mapper-examples/llms.txt

Defines a Context Map for an insurance system, illustrating relationships between Bounded Contexts like Customer Management, Policy Management, and Printing. It uses CML syntax to specify context types, states, and interaction patterns (Upstream-Downstream, Partnership, Shared Kernel, Open Host Service).

```cml
/* Example Context Map for an Insurance System */
ContextMap InsuranceContextMap {
    type = SYSTEM_LANDSCAPE
    state = TO_BE

    /* Add bounded contexts to this context map */
    contains CustomerManagementContext
    contains CustomerSelfServiceContext
    contains PolicyManagementContext
    contains RiskManagementContext
    contains DebtCollection
    contains PrintingContext

    /* Define relationships between contexts */

    /* Upstream-Downstream: CustomerManagement exposes data to SelfService */
    CustomerSelfServiceContext [D,C]<-[U,S] CustomerManagementContext

    /* Partnership: Equal collaboration between Risk and Policy Management */
    RiskManagementContext [P]<->[P] PolicyManagementContext

    /* Shared Kernel: Policy and Debt share common code/models */
    PolicyManagementContext [SK]<->[SK] DebtCollection

    /* Open Host Service with Published Language */
    PrintingContext [U,OHS,PL]->[D,ACL] PolicyManagementContext
}
```

--------------------------------

### Extract Aggregates by Volatility - Output Example (CML)

Source: https://github.com/contextmapper/context-mapper-examples/blob/master/src/main/cml/architectural-refactorings/AR-04-Extract-Aggregates-by-Volatility/README.md

This CML snippet illustrates the output after applying the 'Extract Aggregates by Volatility' refactoring with the volatility parameter set to OFTEN. The original bounded context 'CustomerSelfServiceContext' is modified to exclude the 'CustomerFrontend' aggregate, and a new bounded context 'CustomerSelfServiceContext_Volatility_OFTEN' is created containing only the extracted aggregate.

```cml
BoundedContext CustomerSelfServiceContext implements CustomerManagementDomain {
  domainVisionStatement = "This context represents a web application which allows the customer to login and change basic data records like the address."
  type = APPLICATION
  responsibilities = "AddressChange"
  implementationTechnology = "PHP Web Application"
  
  Aggregate Acounts {
    Entity UserAccount {
      aggregateRoot
      
      String username
      - Customer accountCustomer
    }
  }
}

/**
 * The extracted bounded context after applying 'Extract Aggregates by Volatility'
 * to 'example-input.cml'. The chosen volatility was 'OFTEN'.
 * 
 * You may want to change the name of newly created bounded contexts after applying refactorings.
 */
BoundedContext CustomerSelfServiceContext_Volatility_OFTEN {
  Aggregate CustomerFrontend {
    likelihoodForChange = OFTEN
    
    DomainEvent CustomerAddressChange {
      aggregateRoot
      
      - UserAccount issuer
      - Address changedAddress
    }
  }
}
```

--------------------------------

### Output Context Map after Extract Shared Kernel AR

Source: https://github.com/contextmapper/context-mapper-examples/blob/master/src/main/cml/architectural-refactorings/AR-08-Extract-Shared-Kernel/README.md

This CML snippet shows the resulting Context Map after applying the 'Extract Shared Kernel' AR. The original Shared Kernel relationship is replaced by a new Bounded Context named 'PolicyManagementContext_DebtCollection_SharedKernel', and two upstream-downstream relationships are established connecting this new context to the original ones.

```CML
ContextMap InsuranceContextMap {
  type = SYSTEM_LANDSCAPE
  state = TO_BE
  
  contains PolicyManagementContext
  contains DebtCollection
  contains PolicyManagementContext_DebtCollection_SharedKernel

  /* New relationships generated by the 'Extract Shared Kernel' AR: */
  
  PolicyManagementContext_DebtCollection_SharedKernel [ U ] -> [ D ] PolicyManagementContext

  PolicyManagementContext_DebtCollection_SharedKernel [ U ] -> [ D ] DebtCollection

}

BoundedContext PolicyManagementContext {
  /* ... */
}

BoundedContext DebtCollection {
  /* ... */
}

/* New Bounded Context generated by the 'Extract Shared Kernel' AR. After applying the AR, the Bounded Context can
 * be renamed with the 'Rename Element' refactoring. The user can further specify the comment parts here after applying 
 * the AR (create new Aggregates and entities or move them from existing contexts to this one). 
 */
BoundedContext PolicyManagementContext_DebtCollection_SharedKernel

```

--------------------------------

### Merge Bounded Contexts Example - Output CML

Source: https://github.com/contextmapper/context-mapper-examples/blob/master/src/main/cml/architectural-refactorings/AR-07-Merge-Bounded-Contexts/README.md

This CML snippet shows the result after applying the 'Merge Bounded Contexts' architectural refactoring. The 'CustomerSelfServiceContext' has been merged into 'CustomerManagementContext', combining all their respective aggregates into a single, cohesive bounded context.

```cml
/**
 * The merged bounded context after applying 'Merge Bounded Contexts' to 'example-input.cml'.
 * We selected the 'CustomerSelfServiceContext' context as second bounded context. 
 */
BoundedContext CustomerManagementContext implements CustomerManagementDomain {
  domainVisionStatement = "The customer management context is responsible for managing all the data of the insurance companies customers."
  responsibilities = "Customers, Addresses" , "AddressChange" 
  implementationTechnology = "Java, JEE Application"
  Aggregate Customers {
    Entity Customer {
      aggregateRoot
      
      - SocialInsuranceNumber sin
      String firstname
      String lastname
      - List<Address> addresses
    }
    Entity Address {
      String street
      int postalCode
      String city
    }
    ValueObject SocialInsuranceNumber {
      String sin key
    }
  }
  Aggregate CustomerFrontend {
    DomainEvent CustomerAddressChange {
      aggregateRoot
      
      - UserAccount issuer
      - Address changedAddress
    }
  }
  Aggregate Acounts {
    Entity UserAccount {
      aggregateRoot
      
      String username
      - Customer accountCustomer
    }
  }
}
```

--------------------------------

### Input Bounded Context with Aggregates (CML)

Source: https://github.com/contextmapper/context-mapper-examples/blob/master/src/main/cml/architectural-refactorings/AR-05-Extract-Aggregates-by-Cohesion/README.md

This CML snippet defines a bounded context named 'PolicyManagementContext' containing three aggregates: 'Offers', 'Products', and 'Contract'. It illustrates the initial state before applying the 'Extract Aggregates by Cohesion' refactoring.

```CML
BoundedContext PolicyManagementContext implements PolicyManagementDomain {
  type = FEATURE
  domainVisionStatement = "This bounded context manages the contracts and policies of the customers."
  responsibilities = "Offers, Contracts, Policies"
  implementationTechnology = "Java, Spring App"
  
  Aggregate Offers {
    Entity Offer {
      aggregateRoot
      
      int offerId
      - Customer client
      - List<Product> products
      BigDecimal price
    }
  }
  Aggregate Products {
    Entity Product {
      aggregateRoot
      
      - ProductId identifier
      String productName
    }
    ValueObject ProductId {
      int productId key
    }
  }
  Aggregate Contract {
    Entity Contract {
      aggregateRoot
      
      - ContractId identifier
      - Customer client
      - List<Product> products
    }
    ValueObject ContractId {
      int contractId key
    }
    
    Entity Policy {
      int policyNr
      - Contract contract
      BigDecimal price
    }
  }
}
```

--------------------------------

### Split Bounded Context by Features Output - CML

Source: https://github.com/contextmapper/context-mapper-examples/blob/master/src/main/cml/architectural-refactorings/AR-02-Split-Bounded-Context-by-Features/README.md

This CML code represents the output of the 'Split Bounded Context by Features' refactoring. It shows two distinct bounded contexts, 'PolicyManagementContext' and 'NewBoundedContext1', each encapsulating specific aggregates and responsibilities derived from the original model. The refactoring automatically generates the structure, but manual renaming of elements like 'NewBoundedContext1' is often required for clarity.

```cml
BoundedContext PolicyManagementContext implements PolicyManagementDomain {
  domainVisionStatement = "This bounded context manages the contracts and policies of the customers."
  responsibilities = "Offers, Contracts, Policies"
  implementationTechnology = "Java, Spring App"
  
  Aggregate Contract {
    useCases = UpdateContract
    
    Entity Contract {
      aggregateRoot
      
      - ContractId identifier
      - Customer client
      - List<Product> products
    }
    ValueObject ContractId {
      int contractId key
    }
    
    Entity Policy {
      int policyNr
      - Contract contract
      BigDecimal price
    }
  }
}

/**
 * A new bounded context created by the 'Split Bounded Context by Features' refactoring applied to 'example-input.cml'.
 * 
 * Note that the refactoring does not produce meaningful bounded context names. You can use the 'Rename Element' refactoring (SHIFT-ALT-R) 
 * to rename the new aggregate.
 */
BoundedContext NewBoundedContext1 {
  Aggregate Offers {
    useCases = CreateOffer4Customer
    
    Entity Offer {
      aggregateRoot
      
      int offerId
      - Customer client
      - List<Product> products
      BigDecimal price
    }
  }
  Aggregate Products {
    useCases = CreateOffer4Customer
    
    Entity Product {
      aggregateRoot
      
      - ProductId identifier
      String productName
    }
    ValueObject ProductId {
      int productId key
    }
  }
}
```