### Install Dependencies (Bash)

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/README.md

Installs all the necessary project dependencies using Bundler. This command reads the project's Gemfile and installs the required gems.

```bash
bundle install
```

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

### Install Bundler (Bash)

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/README.md

Installs the bundler gem, a dependency manager for Ruby projects. This is a prerequisite for installing project dependencies.

```bash
gem install bundler
```

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

### Clone and Run Service Cutter with Docker

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/tutorials/systematic-service-decomposition.md

This snippet shows the bash commands to clone the Service Cutter repository and start the application using Docker Compose. Ensure Docker is installed and configured on your system. The service will be accessible at http://localhost:8080.

```bash
git clone git@github.com:ServiceCutter/ServiceCutter.git
cd ServiceCutter
docker-compose up
```

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

### Start a Microservice with Maven Wrapper (Bash)

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/tutorials/jhipster-microservice-generation.md

This command navigates into a specific microservice directory (e.g., CustomerManagement) and then executes the microservice using its Maven wrapper script. This command needs to be run for each generated microservice and the gateway.

```bash
cd CustomerManagement/
./mvnw
```

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

### Run Context Mapper Website (Bash)

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/README.md

Starts a local development server for the Context Mapper website using Jekyll. This command allows you to preview the website locally before deployment.

```bash
bundle exec jekyll serve
```

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

### Claims Application Service Definition

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_cmls/lang-ref-flow-example-2.html

Defines the ClaimsApplicationService with various methods for claim processing. It takes a 'Claim' object as input for each operation.

```DSL
Service ClaimsApplicationService {
  void submitClaim(@Claim claim);
  void checkClaimDocumentation(@Claim claim);
  void checkInsurance(@Claim claim);
  void acceptClaim(@Claim claim);
  void rejectClaim(@Claim claim);
  void schedulePayment(@Claim claim);
  void nofifyCustomer(@Claim claim);
}
```

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

### Model Commands in CML

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/tutorials/event-storming.md

Illustrates modeling commands in Context Mapper DSL. Commands can be modeled as methods in services or as CommandEvents. The examples show abstract CommandEvents and their usage within a Service.

```text
abstract CommandEvent AbstractClaimCommand {
  - Claim claim
}

"role: Administrator in charge"
CommandEvent CheckClaimDocumentation extends @AbstractClaimCommand

"role: Responsible person in claims department"
CommandEvent CheckInsurance extends @AbstractClaimCommand {
  - Set<PolicyId> policies
}

"role: Responsible person in claims department"
CommandEvent AcceptClaim extends @AbstractClaimCommand

"role: Responsible person in claims department"
CommandEvent RejectClaim extends @AbstractClaimCommand

Service ClaimService {
  @ClaimRegistered checkDocumentation(@CheckClaimDocumentation command);

  @AssessmentPerformed checkInsurance(@CheckInsurance command);

  @ClaimAccepted acceptClaim(@AcceptClaim command);

  @ClaimRejected rejectClaim(@RejectClaim commandcal);
}
```

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

### Model Read Models in Context Mapper DSL

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/tutorials/event-storming.md

This example demonstrates how to define a read model in Context Mapper DSL by using separate Aggregates or Entities. It illustrates a basic structure for a 'ClaimReadModel' Aggregate with a 'ClaimReadModel' Entity.

```text
Aggregate ClaimReadModel {
  Entity ClaimReadModel {
    String claimIdentifier
    ...
  }
}
```

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

### Context Mapper DSL: Event and Operation Flow Example

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/language-reference/application-and-process-layer.md

Demonstrates a sequence of events and operations in Context Mapper DSL, showing how events trigger operations and operations emit events. This defines a flow for claim processing and payment scheduling.

```cml
event ClaimAccepted triggers operation schedulePayment
operation schedulePayment emits event PaymentPerformed
event PaymentPerformed triggers operation nofifyCustomer
event ClaimRejected triggers operation nofifyCustomer
operation nofifyCustomer delegates to Claims[ACCEPTED, REJECTED -> CUSTOMER_NOTIFIED] emits event CustomerNotified
```

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

### Claims Application Service API

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_cmls/lang-ref-application-layer-example-3.html

This section details the operations available within the Claims Application Service for managing insurance claims.

```APIDOC
## POST /claims/submit

### Description
Submits a new insurance claim for processing.

### Method
POST

### Endpoint
/claims/submit

### Parameters
#### Request Body
- **claim** (object) - Required - The details of the insurance claim.
  - **claimId** (string) - Required - Unique identifier for the claim.
  - **policyNumber** (string) - Required - The policy number associated with the claim.
  - **claimDetails** (string) - Required - A description of the incident.
  - **dateOfIncident** (string) - Required - The date the incident occurred (YYYY-MM-DD).

### Request Example
```json
{
  "claim": {
    "claimId": "C12345",
    "policyNumber": "POL98765",
    "claimDetails": "Damage to vehicle due to accident.",
    "dateOfIncident": "2023-10-27"
  }
}
```

### Response
#### Success Response (200)
- **status** (string) - The status of the claim submission (e.g., "OPEN").
- **message** (string) - A confirmation message.

#### Response Example
```json
{
  "status": "OPEN",
  "message": "Claim submitted successfully."
}
```

---

## GET /claims/check/{claimId}

### Description
Checks the status of an existing insurance claim.

### Method
GET

### Endpoint
/claims/check/{claimId}

### Parameters
#### Path Parameters
- **claimId** (string) - Required - The unique identifier of the claim to check.

### Response
#### Success Response (200)
- **status** (string) - The current status of the claim (e.g., "OPEN", "ACCEPTED", "REJECTED").
- **details** (string) - Additional details about the claim status.

#### Response Example
```json
{
  "status": "OPEN",
  "details": "Claim is currently under review."
}
```

---

## POST /claims/accept/{claimId}

### Description
Accepts an insurance claim, transitioning its status to ACCEPTED.

### Method
POST

### Endpoint
/claims/accept/{claimId}

### Parameters
#### Path Parameters
- **claimId** (string) - Required - The unique identifier of the claim to accept.

### Response
#### Success Response (200)
- **status** (string) - The updated status of the claim (e.g., "ACCEPTED").
- **message** (string) - A confirmation message.

#### Response Example
```json
{
  "status": "ACCEPTED",
  "message": "Claim has been accepted."
}
```

---

## POST /claims/reject/{claimId}

### Description
Rejects an insurance claim, transitioning its status to REJECTED.

### Method
POST

### Endpoint
/claims/reject/{claimId}

### Parameters
#### Path Parameters
- **claimId** (string) - Required - The unique identifier of the claim to reject.

### Response
#### Success Response (200)
- **status** (string) - The updated status of the claim (e.g., "REJECTED").
- **message** (string) - A confirmation message.

#### Response Example
```json
{
  "status": "REJECTED",
  "message": "Claim has been rejected."
}
```
```

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

### CustomerSelfService to CustomerManagement Integration

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_cmls/jhipster-tutorial-cml-1.html

This snippet defines the relationship between CustomerSelfService and CustomerManagement. It indicates a request/response pattern with CustomerSelfService consuming and sending data to CustomerManagement. It also specifies that CustomerManagement exposes the 'Customers' aggregate.

```ContextMapper
CustomerSelfService [D,C]<-[U,S] CustomerManagement {
    exposedAggregates = Customers
  }
```

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

### CustomerManagement to Printing Integration (SOAP)

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_cmls/jhipster-tutorial-cml-1.html

This snippet defines the integration between CustomerManagement and Printing using SOAP. It shows CustomerManagement depending on and influencing Printing, with Printing exposing its aggregates. The downstream rights are set to INFLUENCER.

```ContextMapper
CustomerManagement [D,ACL]<-[U,OHS,PL] Printing {
    implementationTechnology = "SOAP"
    downstreamRights = INFLUENCER
    exposedAggregates = Printing
  }
```

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

### Claims Flow Definition

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_cmls/lang-ref-flow-example-2.html

Models the ClaimsFlow, outlining the sequence of operations, events, and state transitions for claim processing. It shows how events trigger operations and how operations delegate to stateful entities.

```DSL
Flow ClaimsFlow {
  operation submitClaim emits event ClaimSubmitted
  event ClaimSubmitted triggers operation checkClaimDocumentation
  operation checkClaimDocumentation emits event ClaimRegistered
  event ClaimRegistered triggers operation checkInsurance
  operation checkInsurance emits event AssessmentPerformed
  
  event AssessmentPerformed triggers operation acceptClaim X rejectClaim 
  operation acceptClaim delegates to Claims [OPEN -> ACCEPTED] emits event ClaimAccepted
  operation rejectClaim delegates to Claims [OPEN -> REJECTED] emits event ClaimRejected
  
  event ClaimAccepted triggers operation schedulePayment
  operation schedulePayment emits event PaymentPerformed
  event PaymentPerformed triggers operation nofifyCustomer
  event ClaimRejected triggers operation nofifyCustomer
  operation nofifyCustomer delegates to Claims[ACCEPTED, REJECTED -> CUSTOMER_NOTIFIED] emits event CustomerNotified
}
```

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

### Define Subsystem Components with Context Mapper DSL

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_cmls/team-map-generator-example-1.html

This snippet defines the core subsystems or components within the organizational map. These are declared as BoundedContexts and serve as the building blocks for team responsibilities and inter-context relationships.

```Context Mapper DSL
/* Subsystem/component definitions */
  BoundedContext CustomerManagementContext
  BoundedContext CustomerSelfServiceContext
  BoundedContext PolicyManagementContext
  BoundedContext RiskManagementContext
```

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

### ClaimsFlow Definition in Context Mapper DSL

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_cmls/lang-ref-flow-example-1.html

This snippet defines a 'ClaimsFlow' using the Context Mapper DSL. It outlines a sequence of commands and events, including delegation to bounded contexts and state transitions. The flow starts with submitting a claim and ends with notifying the customer.

```text
Application {

  /* we removed commands and events here to keep the sample shorter */

  Flow ClaimsFlow {
    command SubmitClaim emits event ClaimSubmitted
    event ClaimSubmitted triggers command CheckClaimDocumentation
    command CheckClaimDocumentation emits event ClaimRegistered
    event ClaimRegistered triggers command CheckInsurance
    command CheckInsurance emits event AssessmentPerformed

    event AssessmentPerformed triggers command AcceptClaim X RejectClaim 
    command AcceptClaim delegates to Claims [OPEN -> ACCEPTED] emits event ClaimAccepted
    command RejectClaim delegates to Claims [OPEN -> REJECTED] emits event ClaimRejected

    event ClaimAccepted triggers command SchedulePayment
    command SchedulePayment emits event PaymentPerformed
    event PaymentPerformed triggers command NofifyCustomer
    event ClaimRejected triggers command NofifyCustomer
    command NofifyCustomer delegates to Claims [ACCEPTED, REJECTED -> CUSTOMER_NOTIFIED] emits event CustomerNotified
  }
}
```

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

### Create and Navigate to Microservice Directory (Bash)

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/tutorials/jhipster-microservice-generation.md

These bash commands are used to create a new directory for microservice generation and then change the current directory to the newly created one. This sets up the workspace for the JHipster generation process.

```bash
mkdir microservice-tutorial
cd microservice-tutorial/
```

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

### MDSL Service Contract Example

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/generators/generators.md

An example of a Microservice Domain Specific Language (MDSL) service contract generated from a DDD Context Map. It defines data types, API endpoints, operations, and provider/client relationships.

```mdsl
// Generated from DDD Context Map 'Insurance-Example_Context-Map.cml' at 21.10.2019 17:48:52 CEST.
API description CustomerManagementContextAPI
usage context PUBLIC_API for BACKEND_INTEGRATION

data type Address { "street":V<string>, "postalCode":V<int>, "city":V<string> }
data type AddressId P
data type changeCustomerParameter { "firstname":V<string>, "lastname":V<string> }

endpoint type CustomersAggregate
  serves as INFORMATION_HOLDER_RESOURCE
  exposes
    operation createAddress
      with responsibility "Creates new address for customer"
      expecting
        payload Address
      delivering
        payload AddressId
    operation changeCustomer
      with responsibility "Changes existing customer address"
      expecting
        payload changeCustomerParameter
      delivering
        payload V<bool>

// Generated from DDD upstream Bounded Context 'CustomerManagementContext' implementing OPEN_HOST_SERVICE (OHS) and PUBLISHED_LANGUAGE (PL).
API provider CustomerManagementContextProvider
  // The customer management context is responsible for managing all the data of the insurance companies customers.
  offers CustomersAggregate
  at endpoint location "http://localhost:8001"
    via protocol "RESTfulHTTP"

// Generated from DDD upstream Bounded Context 'CustomerManagementContext' implementing OPEN_HOST_SERVICE (OHS) and PUBLISHED_LANGUAGE (PL).
API client PolicyManagementContextClient
  // This bounded context manages the contracts and policies of the customers.
  consumes CustomersAggregate
API client CustomerSelfServiceContextClient
  // This context represents a web application which allows the customer to login and change basic data records like the address.
  consumes CustomersAggregate

IPA

```

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

### Illustrate Event Flow with Comments in Context Mapper DSL

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/tutorials/event-storming.md

This example shows how to indicate event flow and command triggers in Context Mapper DSL using comments. It sequences command and domain events, using '// triggers ...' comments to denote the causal relationship and temporal order.

```text
"role: Administrator in charge"
CommandEvent CheckClaimDocumentation extends @AbstractClaimCommand	
DomainEvent ClaimRegistered extends @AbstractClaimEvent // triggers CheckInsurance command
	
"role: Responsible person in claims department"
CommandEvent CheckInsurance extends @AbstractClaimCommand {
	- Set<PolicyId> policies
}

DomainEvent AssessmentPerformed extends @AbstractClaimEvent // triggers AcceptClaim or RejectClaim command	
	
"role: Responsible person in claims department"
CommandEvent AcceptClaim extends @AbstractClaimCommand

DomainEvent ClaimAccepted extends @AbstractClaimEvent // triggers SchedulePayment command	
	
"role: Responsible person in claims department"
CommandEvent RejectClaim extends @AbstractClaimCommand

DomainEvent ClaimRejected extends @AbstractClaimEvent // triggers NofifyCustomer command
```

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

### Define Claims Application Service with State Transitions (Context Mapper DSL)

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_cmls/lang-ref-application-layer-example-3.html

This snippet defines a service named ClaimsApplicationService within a bounded context. It includes methods for submitting, checking, accepting, and rejecting claims, along with state transition definitions for the 'OPEN', 'ACCEPTED', and 'REJECTED' states.

```DSL
Application {
  Service ClaimsApplicationService {
    void submitClaim(@Claim claim) : write [ -> OPEN];
    void checkInsurance(@Claim claim);
    void acceptClaim(@Claim claim) : write [ OPEN -> ACCEPTED ];
    void rejectClaim(@Claim claim) : write [ OPEN -> REJECTED ];
  }
}
```

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

### Value Narrative Notation Example in CML

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/language-reference/values.md

Presents the Value Narrative notation in CML, describing a scenario for 'same day delivery'. It outlines stakeholder expectations regarding promoting, protecting, or creating values, while potentially degrading others, and includes a specific behavioral example.

```cml
ValueRegister Same_Day_Delivery_Sample {
  ValueNarrative Sample_Narrative {
    When the SOI executes "the same say delivery epic (incl. split user stories that meet the INVEST criteria)",
    stakeholders expect it to promote, protect or create "freedom and quality of life",
    possibly degrading or prohibiting "work-life balance of suppliers and shopper privacy"
    with the following externally observable and/or internally auditable behavior:

    "Given: Shop is operational and suited suppliers and logistics firms are available. 
    When: Same day delivery is promised during order acceptance and confirmation. 
    Then: Order arrives at shipment address until 11:59pm on the same say."
  }
}
```

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

### Define Use Case: Get paid for car accident (Context Mapper)

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_cmls/lang-ref-use-case-4.html

This snippet defines a Use Case using Context Mapper DSL. It specifies the primary actor, scope, level, benefit, and a detailed sequence of interactions for the 'Get paid for car accident' scenario.

```Context Mapper
UseCase Get_paid_for_car_accident {
  actor "Claimant"
  scope "Insurance company"
  level "Summary"
  benefit "A claimant submits a claim and and gets paid from the insurance company."
  interactions
    "submit" a "Claim",
    "verifyExistanceOf" "Policy",
    "assign" an "Agent" for a "Claim",
    "verify" "Policy",
    "pay" "Claimant",
    "close" "Claim"
}
```

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

### Emit Multiple Events from Command/Operation (All)

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/language-reference/application-and-process-layer.md

Demonstrates how to specify that a command or operation emits multiple events, where all listed events are emitted. This uses the '+' symbol. No external dependencies are required for this syntax.

```text
command SubmitClaim emits event Event1 + Event2 + Event3

// alternative
operation submitClaim emits event Event1 + Event2
```

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

### CustomersAggregate API

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_mdsls/insurance-example.html

Operations exposed by the CustomersAggregate, serving as an information holder resource.

```APIDOC
## POST /customers/addresses

### Description
Creates a new address for a customer.

### Method
POST

### Endpoint
/customers/addresses

### Parameters
#### Request Body
- **street** (string) - Required - The street name.
- **postalCode** (int) - Required - The postal code.
- **city** (string) - Required - The city name.

### Request Example
```json
{
  "street": "123 Main St",
  "postalCode": 12345,
  "city": "Anytown"
}
```

### Response
#### Success Response (200)
- **addressId** (AddressId) - The ID of the newly created address.

#### Response Example
```json
{
  "addressId": "addr-12345"
}
```

## PUT /customers/change

### Description
Changes an existing customer's details.

### Method
PUT

### Endpoint
/customers/change

### Parameters
#### Request Body
- **firstname** (string) - Required - The customer's first name.
- **lastname** (string) - Required - The customer's last name.

### Request Example
```json
{
  "firstname": "John",
  "lastname": "Doe"
}
```

### Response
#### Success Response (200)
- **success** (boolean) - Indicates if the customer change was successful.

#### Response Example
```json
{
  "success": true
}
```
```

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

### CustomersAggregate API

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_mdsls/insurance-example-full.html

Provides operations for managing customer data, including creating addresses and changing customer details.

```APIDOC
## POST /customers/{customerId}/addresses

### Description
Creates a new address for a given customer.

### Method
POST

### Endpoint
/customers/{customerId}/addresses

### Parameters
#### Path Parameters
- **customerId** (string) - Required - The ID of the customer to add an address to.

#### Request Body
- **street** (string) - Required - The street name of the address.
- **postalCode** (integer) - Required - The postal code of the address.
- **city** (string) - Required - The city of the address.

### Request Example
```json
{
  "street": "123 Main St",
  "postalCode": 12345,
  "city": "Anytown"
}
```

### Response
#### Success Response (200)
- **addressId** (string) - The unique identifier for the newly created address.

#### Response Example
```json
{
  "addressId": "addr_123abc"
}
```

## PUT /customers/{customerId}/details

### Description
Changes existing customer details, such as their address.

### Method
PUT

### Endpoint
/customers/{customerId}/details

### Parameters
#### Path Parameters
- **customerId** (string) - Required - The ID of the customer to update.

#### Request Body
- **firstname** (string) - Optional - The new first name for the customer.
- **lastname** (string) - Optional - The new last name for the customer.

### Request Example
```json
{
  "firstname": "Jane",
  "lastname": "Doe"
}
```

### Response
#### Success Response (200)
- **success** (boolean) - Indicates whether the customer details were successfully changed.

#### Response Example
```json
{
  "success": true
}
```
```

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

### Context Mapper DSL: Basic Flow Grammar Syntax

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/language-reference/application-and-process-layer.md

Illustrates the fundamental syntax for defining event production and command invocation flows in the Context Mapper DSL. It shows both command and operation variations for emitting events and triggering commands/operations.

```cml
Application {
  Flow ClaimsFlow {
    command SubmitClaim emits event ClaimSubmitted
    operation submitClaim emits event ClaimSubmitted
    event ClaimSubmitted triggers command CheckClaimDocumentation
    event ClaimSubmitted triggers operation checkClaimDocumentation
  }
}
```

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

### CustomerManagementContextAPI Definition

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_mdsls/insurance-example-full.html

Defines the API for the Customer Management Context, specifying data types and operations. It is exposed as a PUBLIC_API for BACKEND_INTEGRATION.

```cml
// Generated from DDD Context Map 'Insurance-Example\_Context-Map.cml' at 21.10.2019 17:48:52 CEST.
API description CustomerManagementContextAPI
usage context PUBLIC_API for BACKEND_INTEGRATION

// ** BEGIN PROTECTED REGION for data types

// ** END PROTECTED REGION for data types

data type Address { "street":D<string>, "postalCode":D<int>, "city":D<string> }
data type AddressId P
data type changeCustomerParameter { "firstname":D<string>, "lastname":D<string> }

// ** BEGIN PROTECTED REGION for endpoint types

// ** END PROTECTED REGION for endpoint types

endpoint type CustomersAggregate
  serves as INFORMATION_HOLDER_RESOURCE
  exposes
    operation createAddress
      with responsibility "Creates new address for customer"
      expecting
        payload Address
      delivering
        payload AddressId
    operation changeCustomer
      with responsibility "Changes existing customer address"
      expecting
        payload changeCustomerParameter
      delivering
        payload D<bool>
```

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

### List Generated Microservice Directories (Bash)

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/tutorials/jhipster-microservice-generation.md

After JHipster generation, this command lists the contents of the current directory. It shows the generated directories, each corresponding to a microservice (Bounded Context) and the API gateway.

```bash
ls -l
```

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

### PolicyManagementContextClient API Client

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_mdsls/insurance-example-full.html

Defines the API client for the Policy Management Context, consuming the CustomersAggregate. This context manages contracts and policies.

```cml
// Generated from DDD downstream Bounded Context 'PolicyManagementContext' implementing CONFORMIST (CF).
API client PolicyManagementContextClient
  // This bounded context manages the contracts and policies of the customers.
  consumes CustomersAggregate
```

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

### Model User Stories and Use Cases in CML

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/modeling-tools/rapid-ooad.md

Demonstrates the basic syntax for defining User Stories and Use Cases in Context Mapper DSL. Supports the role-feature-reason structure for both.

```cml
UserStory US1_Example {
  As an "Insurance Employee" I want to "create" a "Customer" so that "I am able to manage customer data ..."
}

UseCase UC1_Example {
  actor = "Insurance Employee"
  interactions = "create" a "Customer"
  benefit = "I am able to manage customer data ..."
}
```

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

### Context Map and Bounded Contexts for Split System

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/modeling-tools/rapid-ooad.md

This code defines a Context Map with three systems: CustomerManagementFrontend, CustomerManagementDomainLogic, and CustomerManagementDatabase. It also defines the Bounded Contexts for each system, specifying their types, implementation technologies, and aggregates. The relationships between these systems are defined using PL (Partnership) and CF (Customer-Supplier) notations.

```ContextMapper DSL
ContextMap {
  contains CustomerManagementFrontend
  contains CustomerManagementDomainLogic
  contains CustomerManagementDatabase

  CustomerManagementDomainLogic [PL] -> [CF] CustomerManagementFrontend {
    implementationTechnology "RESTful HTTP"
    exposedAggregates CustomerManagementAggregateBackend
  }

  CustomerManagementDatabase [PL] -> [CF] CustomerManagementDomainLogic {
    implementationTechnology "JDBC"
  }
}

BoundedContext CustomerManagementFrontend implements CustomerManagement {
  domainVisionStatement "This Bounded Context realizes the following subdomains: CustomerManagement"
  type SYSTEM
  implementationTechnology "Angular"
  Aggregate CustomerManagementAggregateViewModel {
    Service US1_ExampleService {
      CreateCustomerOutput createCustomer (CreateCustomerInput input);
      UpdateCustomerOutput updateCustomer (UpdateCustomerInput input);
      OfferContractOutput offerContract (OfferContractInput input);
    }
    Entity CustomerViewModel {
      CustomerID customerId
    }
    Entity ContractViewModel {
      ContractID contractId
    }
  }
}

BoundedContext CustomerManagementDomainLogic implements CustomerManagement {
  domainVisionStatement "This Bounded Context realizes the following subdomains: CustomerManagement"
  type SYSTEM
  implementationTechnology "Sprint Boot"
  Aggregate CustomerManagementAggregateBackend {
    Service US1_ExampleService {
      CreateCustomerOutput createCustomer (CreateCustomerInput input);
      UpdateCustomerOutput updateCustomer (UpdateCustomerInput input);
      OfferContractOutput offerContract (OfferContractInput input);
    }
    Entity CustomerBackend {
      CustomerID customerId
    }
    Entity ContractBackend {
      ContractID contractId
    }
  }
}

BoundedContext CustomerManagementDatabase {
  type SYSTEM
  implementationTechnology "JDBC"
}
```

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

### Reference Application Service Operation in Coordination Step

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/language-reference/application-and-process-layer.md

Illustrates the syntax for referencing an application service operation within a coordination step. The format is 'Bounded Context name :: application service name :: service operation name'. This example shows a call to the 'submitClaim' operation provided by the 'ClaimsApplicationService' in the 'ClaimsManagement' Bounded Context.

```cml
// Bounded context name :: application service name :: service operation name
ClaimsManagement::ClaimsApplicationService::submitClaim;
```

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

### Java Value Object Definition

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/tutorials/architecture-validation-with-archunit.md

Defines a Java class annotated with @ValueObject. This snippet is part of an example demonstrating how ArchUnit can detect unmodeled value objects.

```java
package org.contextmapper.archunit.example.domain.product;

import org.jmolecules.ddd.annotation.AggregateRoot;
import org.jmolecules.ddd.annotation.Entity;

import java.math.BigDecimal;

@Entity
@AggregateRoot
public class Product {

    private ProductId id;
    private String name;
    private String description;
    private BigDecimal price;
    private ProductDetail detail;

    // we removed the rest of the code to simplify the examples ...

}
```

```java
package org.contextmapper.archunit.example.domain.product;

@ValueObject
public class ProductDetail {
}
```

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

### Model Aggregates in CML

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/tutorials/event-storming.md

Demonstrates modeling Aggregates in Context Mapper DSL, which can be contained within Bounded Contexts. The example shows an Aggregate named 'Notification' with an Entity, CommandEvent, DomainEvent, and Service.

```text
Aggregate Notification {
  Entity Notification {
    aggregateRoot
    
    - Claim claim
  }
  
  CommandEvent NofifyCustomer
  
  DomainEvent CustomerNotified {
    Date timestamp
  }
  
  Service NotificationService {
    @CustomerNotified notifyCustomer(@NofifyCustomer command);
  }
}
```

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

### Run JHipster Registry (Bash)

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/tutorials/jhipster-microservice-generation.md

This command downloads the JHipster Registry JAR file and then runs it using Java. It includes specific Spring profiles and security configurations required for the registry to function as a service discovery server.

```bash
wget https://github.com/jhipster/jhipster-registry/releases/download/v6.1.2/jhipster-registry-6.1.2.jar
java -jar jhipster-registry-6.1.2.jar --spring.profiles.active=dev --spring.security.user.password=admin --jhipster.security.authentication.jwt.secret=my-secret-key-which-should-be-changed-in-production-and-be-base64-encoded --spring.cloud.config.server.composite.0.type=git --spring.cloud.config.server.composite.0.uri=https://github.com/jhipster/jhipster-registry-sample-config
```

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

### RiskManagement and PolicyManagement Integration (RabbitMQ)

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_cmls/jhipster-tutorial-cml-1.html

This snippet defines a bidirectional relationship between RiskManagement and PolicyManagement using RabbitMQ. This suggests a publish-subscribe or event-driven communication pattern between these two contexts.

```ContextMapper
RiskManagement [P]<->[P] PolicyManagement {
    implementationTechnology = "RabbitMQ"
  }
```

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

### ArchUnit Test Failure Example

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/tutorials/architecture-validation-with-archunit.md

Illustrates a typical ArchUnit test failure message when a Java value object is not modeled in CML. This output indicates a violation of the 'valueObjectsShouldBeModeledInCML' rule.

```text
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.701 s - in org.contextmapper.archunit.example.SampleApplicationTest
2021-05-31 08:48:54.186  INFO 15800 --- [extShutdownHook] o.s.s.concurrent.ThreadPoolTaskExecutor  : Shutting down ExecutorService 'applicationTaskExecutor'
[INFO] 
[INFO] Results:
[INFO] 
[ERROR] Failures: 
[ERROR]   CmlArchUnitTestExample.valueObjectsShouldBeModeledInCML:64 Architecture Violation [Priority: MEDIUM] - Rule 'classes that are annotated with @ValueObject should be modeled as value object in CML.' was violated (1 times):
The value object 'ProductDetail' is not modeled in CML.
[INFO] 
[ERROR] Tests run: 26, Failures: 1, Errors: 0, Skipped: 0
[INFO] 

```

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

### DebtCollection to Printing Integration (SOAP)

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_cmls/jhipster-tutorial-cml-1.html

This snippet defines the integration between DebtCollection and Printing using SOAP. DebtCollection depends on and has access to Printing, with Printing exposing its aggregates. This suggests DebtCollection might use Printing services, possibly for generating documents.

```ContextMapper
DebtCollection [D,ACL]<-[U,OHS,PL] Printing {
    implementationTechnology = "SOAP"
    exposedAggregates = Printing
  }
```

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

### Import JDL File with JHipster Generator (Bash)

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/tutorials/jhipster-microservice-generation.md

This command initiates the JHipster generator to import a JDL (JHipster Domain Language) file. The JDL file defines the microservices, entities, and relationships. Ensure the path to the JDL file is correct.

```bash
jhipster import-jdl ./../context-mapper-examples/src-gen/insurance-microservices.jdl
```

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

### Declare State Transitions in Flow Steps (Context Mapping Language)

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/language-reference/application-and-process-layer.md

This snippet demonstrates how to declare state transitions for flow steps that delegate to an Aggregate. It shows the syntax for both 'command' and 'operation' types, including the target state and emitted events. This allows state transitions to be modeled directly within flow steps instead of solely within Aggregate operations.

```cml
command SubmitClaim delegates to Claims [ -> SUBMITTED ] emits event Event1 X Event2 X Event3

// alternative
operation submitClaim delegates to Claims [ -> SUBMITTED ] emits event Event1 X Event2
```

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

### Specify Initiating Actors for Commands/Operations (Context Mapping Language)

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/language-reference/application-and-process-layer.md

This snippet illustrates how to optionally specify the actor or user that initiates a command or operation in Context Mapper. It shows the syntax for adding the 'initiated by' clause to both 'command' and 'operation' definitions, linking them to the target Aggregate and emitted events.

```cml
command SubmitClaim [ initiated by "Customer" ] delegates to Claims [ -> SUBMITTED ] emits event Event1

// alternative
operation submitClaim [ initiated by "Customer" ] delegates to Claims [ -> SUBMITTED ] emits event Event1
```

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

### Define Bounded Context: Customer Management Database (Context Mapper DSL)

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_cmls/rapid-ooad-listing-6.html

This snippet defines the 'CustomerManagementDatabase' bounded context, specifying its type and implementation technology as JDBC.

```Context Mapper DSL
BoundedContext CustomerManagementDatabase {
  type SYSTEM
  implementationTechnology "JDBC"
}
```

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

### Define InsuranceContextMap System Landscape

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_cmls/jhipster-tutorial-cml-1.html

This snippet defines the overall system landscape for the insurance context. It specifies the type as SYSTEM_LANDSCAPE and the state as TO_BE. It lists the bounded contexts contained within this landscape.

```ContextMapper
ContextMap InsuranceContextMap {
  type = SYSTEM_LANDSCAPE
  state = TO_BE

  contains CustomerManagement, CustomerSelfService, Printing
  contains PolicyManagement, RiskManagement, DebtCollection
}
```

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

### Discover and Serialize Context Map with Java

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/reverse-engineering/reverse-engineering.md

This Java code snippet demonstrates how to use the ContextMapDiscoverer library to automatically discover bounded contexts and relationships from a microservices project. It configures strategies for Spring Boot applications and Docker Compose files, maps bounded context names, and serializes the resulting context map to a CML file.

```java
import java.io.File;
import java.io.IOException;

import org.contextmapper.dsl.ContextMappingDSLStandaloneSetup;
import org.contextmapper.dsl.contextMappingDSL.ContextMap;
import org.contextmapper.dsl.generator.ContextMapSerializer;
import org.contextmapper.dsl.provider.ContextMapDiscoverer;
import org.contextmapper.dsl.strategy.boundedcontext.docker.DockerComposeRelationshipDiscoveryStrategy;
import org.contextmapper.dsl.strategy.boundedcontext.naming.SeparatorToCamelCaseBoundedContextNameMappingStrategy;
import org.contextmapper.dsl.strategy.boundedcontext.spring.SpringBootBoundedContextDiscoveryStrategy;

public class LakesideMutualContextMapDiscoverer {

  public static void main(String[] args) throws IOException {
    // configure the discoverer
    ContextMapDiscoverer discoverer = new ContextMapDiscoverer()
        .usingBoundedContextDiscoveryStrategies(
            new SpringBootBoundedContextDiscoveryStrategy("com.lakesidemutual"))
        .usingRelationshipDiscoveryStrategies(
            new DockerComposeRelationshipDiscoveryStrategy(
                new File(System.getProperty("user.home") + "/source/LakesideMutual/")))
        .usingBoundedContextNameMappingStrategies(
            new SeparatorToCamelCaseBoundedContextNameMappingStrategy("-") {
              @Override
              public String mapBoundedContextName(String s) {
                // remove the "Backend" part of the Docker service names to map correctly...
                String name = super.mapBoundedContextName(s);
                return name.endsWith("Backend") ? name.substring(0, name.length() - 7) : name;
              }
            });

    // run the discovery process to get the Context Map
    ContextMap contextmap = discoverer.discoverContextMap();

    // serialize the Context Map to CML
    new ContextMapSerializer().serializeContextMap(contextmap, new File("./src-gen/lakesidemutual.cml"));
  }

}
```

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

### Emit Inclusive OR Events from Command/Operation

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/language-reference/application-and-process-layer.md

Shows how to specify that a command or operation emits one or multiple, but not necessarily all, events from a list using the 'O' symbol. This is similar to an inclusive gateway in BPMN.

```text
command SubmitClaim emits event Event1 O Event2 O Event3

// alternative
operation submitClaim emits event Event1 O Event2
```

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

### Define Insurance Context Map in CML

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/tutorials/jhipster-microservice-generation.md

This CML snippet defines the overall Context Map for the insurance example, specifying Bounded Contexts and their relationships. It includes details like exposed aggregates and implementation technologies for inter-context communication.

```cml
ContextMap InsuranceContextMap {
  type = SYSTEM_LANDSCAPE
  state = TO_BE

  contains CustomerManagement, CustomerSelfService, Printing
  contains PolicyManagement, RiskManagement, DebtCollection

  CustomerSelfService [<span class="k">D</span>,<span class="k">C</span>]&lt;-[<span class="k">U</span>,<span class="k">S</span>] CustomerManagement {
    exposedAggregates = Customers
  }

  CustomerManagement [<span class="k">D</span>,<span class="k">ACL</span>]&lt;-[<span class="k">U</span>,<span class="k">OHS</span>,<span class="k">PL</span>] Printing {
    implementationTechnology = "SOAP"
    downstreamRights = INFLUENCER
    exposedAggregates = Printing
  }

  Printing [<span class="k">U</span>,<span class="k">OHS</span>,<span class="k">PL</span>]-&gt;[<span class="k">D</span>,<span class="k">ACL</span>] PolicyManagement {
    implementationTechnology = "SOAP"
    exposedAggregates = Printing
  }

  RiskManagement [<span class="k">P</span>]&lt;-&gt;[<span class="k">P</span>] PolicyManagement {
    implementationTechnology = "RabbitMQ"
  }

  PolicyManagement [<span class="k">D</span>,<span class="k">CF</span>]&lt;-[<span class="k">U</span>,<span class="k">OHS</span>,<span class="k">PL</span>] CustomerManagement {
    implementationTechnology = "RESTfulHTTP"
    exposedAggregates = Customers
  }

  DebtCollection [<span class="k">D</span>,<span class="k">ACL</span>]&lt;-[<span class="k">U</span>,<span class="k">OHS</span>,<span class="k">PL</span>] Printing {
    implementationTechnology = "SOAP"
    exposedAggregates = Printing
  }

  PolicyManagement [<span class="k">SK</span>]&lt;-&gt;[<span class="k">SK</span>] DebtCollection {
    implementationTechnology = "Shared Java Library, Communication over RESTful HTTP"
  }
}

```

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

### Command Delegation to Aggregate with Event Emission (Context Mapper DSL)

Source: https://github.com/contextmapper/contextmapper.github.io/blob/master/_docs/language-reference/application-and-process-layer.md

Illustrates a command that delegates its execution to a specific aggregate and subsequently emits one or more events. This pattern is common in Domain-Driven Design. This syntax is specific to the Context Mapper DSL.

```Context Mapper DSL
command SubmitClaim delegates to Claims emits event Event1 X Event2 X Event3

// alternative
operation submitClaim delegates to Claims emits event Event1 X Event2
```