Skip to content
CONTEXT MAPPER
  • Docs
  • Language Reference
  • Generators
  • News
  • Background
  • Get Involved
    Introduction
    • Welcome
    • Getting started
    • Create CML Project
    • Examples
    • Usage as Library
    • Frequently Asked Questions
    Language Reference (Core)
    • CML Reference - Introduction
    • Language Semantics
    • Context Map
    • Bounded Context
    • Domain and Subdomain
    • Domain Vision Statement
    • Partnership
    • Shared Kernel
    • Customer/Supplier
    • Conformist
    • Open Host Service
    • Anticorruption Layer
    • Published Language
    • Responsibility Layers
    • Knowledge Level
    • Aggregate
    • Tactic DDD Syntax
    • Application and Process Layer
    • User Requirements
    • Stakeholders
    • Value Registers
    • Imports
    Analysis and Design Transformations
    • Rapid Object-oriented Analysis and Design
    • Story Splitting (PoC)
    • Stakeholder and Value Modelling Transformations
    Architectural Refactorings (ARs)
    • Architectural Refactorings
    • AR-1: Split Aggregate by Entities
    • AR-2: Split Bounded Context by Features
    • AR-3: Split Bounded Context by Owner
    • AR-4: Extract Aggregates by Volatility
    • AR-5: Extract Aggregates by Cohesion
    • AR-6: Merge Aggregates
    • AR-7: Merge Bounded Contexts
    • AR-8: Extract Shared Kernel
    • AR-9: Suspend Partnership
    • AR-10: Change Shared Kernel to Partnership
    • AR-11: Change Partnership to Shared Kernel
    Value-Driven Analysis and Design
    • Value-Driven Analysis and Design (VDAD) Support
    Service Cutter
    • Context Map Suggestions with Service Cutter
    • Service Cutter Configuration File (.servicecutter.yml)
    Reverse Engineering
    • Context Map Discovery
    Generators
    • Generators Overview
    • Context Map Generator
    • PlantUML Generator
    • BPMN Sketch Miner Generator
    • MDSL (Micro-)Service Contracts Generator
    • Service Cutter Generators
    • Generic Generator (Templating)
    Tutorials
    • Model Event Storming Results in Context Mapper
    • Event Sourcing and CQRS Modeling in Context Mapper
    • Generate Microservices From Context Map Using JHipster
    • Systematic Service Decomposition with Context Mapper and Service Cutter
    • Validating the Implementation against the Model (with ArchUnit)
    IDE Plugins and Extensions
    • Visual Studio Code Extension
    • Online IDE (no longer supported)
    • Eclipse Plugin
    • Feature Support

    Tactic DDD Syntax

    The Context Mapper syntax for the tactic DDD part is based on the Sculptor DSL. For this reason we do not document all details of the tactic language part, since all the information can be found in Sculptor’s documentation. However, we still provide a short introduction into the most important elements on this page.

    Aggregates

    The stategic DDD’s bounded contexts typically contain multiple aggregates. Within the aggregates, you can model your system with the tactic DDD patterns, such as Entity, Value Object, Domain Event, Service and Repository.

    The page Aggregate describes how you can create aggregates. The following sections introduce the other patterns syntax briefly. All of those language elements can be used within the aggregate.

    Entity

    An entity is declared with the Entity keyword, as illustrated below. With the optional keyword aggregateRoot you can specify which entity within your aggregate is the root entity. The language provides primitive data types such as String, int and boolean etc., similar to Java. You can further use the collection types List, Set and Bag.

    Entity Customer {
      aggregateRoot
    
      SocialInsuranceNumber sin
      String firstname
      String lastname
      List<Address> addresses
    }
    

    As illustrated in the example above, you can declare your own types (such as Address and SocialInsuranceNumber above). These types don’t have to be further specified anywhere. However, you can also use references to existing types (entities, value objects, etc.) as described below.

    Type References

    To reference another type of your model within an attribute, you have to use the - (minus) sign:

    Aggregate Customers {
      Entity Customer {
        aggregateRoot
    
        - SocialInsuranceNumber sin // Reference syntax for simple attribute
        String firstname
        String lastname
        - List<Address> addresses // Reference syntax for collections
      }
    
      Entity Address {
        String street
        int postalCode
        String city
      }
    
      ValueObject SocialInsuranceNumber {
        String sin key
      }
    }
    

    When you use this reference notation with the - (minus) sign, the language checks that the types (Address and SocialInsuranceNumber above) are declared.

    Operations / Methods

    Of course you can also declare methods/operations on your Entities, Value Objects and Domain Events. The declaration of methods is started with the def keyword. As illustrated below, you can use abstract data types which are not further declared in your method parameters and return types:

    Entity Customer {
      aggregateRoot
    
      - SocialInsuranceNumber sin
      String firstname
      String lastname
      - List<Address> addresses
    
      def AddressId createAddress(Address address);
      def void changeCustomer(Customer customer, Address address);
    }
    

    If you want to refer existing types in your operation/method parameters and return types, you have to use the @ character:

    Aggregate Customers {
      Entity Customer {
        aggregateRoot
    
        - SocialInsuranceNumber sin
        String firstname
        String lastname
        - List<Address> addresses
    
        def @AddressId createAddress(@Address address); // Method/Operation declaration with references
        def void changeCustomer(@Customer customer, @Address address); // Method/Operation declaration with references
      }
    
      Entity Address {
        String street
        int postalCode
        String city
      }
    
      ValueObject SocialInsuranceNumber {
        String sin key
      }
    
      ValueObject AddressId {
        int id
      }
    }
    

    Value Objects

    The declaration of value objects is done with the ValueObject keyword:

    ValueObject HandlingHistory {
      - List<HandlingEvent> handlingEvents
    }
    

    Attributes & Methods/Operations

    Attributes (incl. type references) and methods/operations in value objects can be specified exactly the same way as within entities (see sections above).

    Domain Events

    The declaration of domain events is done with the DomainEvent keyword: (alternatively you can use the keyword Event)

    DomainEvent HandlingEvent {
      Type handlingType;
      - Voyage voyage;
      - LocationShared location;
      Date completionTime;
      Date registrationTime;
      - Cargo cargo;
    }
    

    Commands

    The declaration of commands is done with the Command keyword: (alternatively you can use the original Sculptor keyword CommandEvent)

    Command RejectClaim {
      - Claim claim2Reject
      - Employee decisionMaker
      String reason4Rejection
    }
    

    Attributes & Methods/Operations

    Attributes (incl. type references) and methods/operations in domain events can be specified exactly the same way as within entities (see sections above).

    Services

    Within your bounded context (or also inside aggregates) you can specify domain services according to the tactic DDD Service pattern. Domain services are declared with the Service keyword and contain one or more methods/operations. These methods/operations are declared exactly the same way as within entities, value objects or domain events, but without the def keyword:

    Service RoutingService {
      List<@Itinerary> fetchRoutesForSpecification(@RouteSpecification routeSpecification) throws LocationNotFoundException;
    }
    

    With the throws keyword you can specify that the method/operation can throw a specific exception (as in Java).

    Note: The MDSL generator currently only makes use of domain services that are declared inside aggregates that are exposed in your Context Map.

    Repositories

    You can specify a repository with the Repository keyword within your aggregate root. Only aggregate roots can contain repositories, which is ensured by a semantic checker of the language. A repository can contain one or more methods/operations, as illustrated in the example below. These methods/operations are declared exactly the same way as within entities, value objects or domain events, but without the def keyword:

    Aggregate Location {
      Entity Location {
        aggregateRoot
    
        PortCode portcode
        - UnLocode unLocode;
        String name;
    
        Repository LocationRepository {
          @Location find(@UnLocode unLocode);
          List<@Location> findAll();
        }
      }
    
      ValueObject UnLocode {
        String unLocode
      }
    
      ValueObject LocationShared {
        PortCode portCode
        - Location location
      }
    }
    

    More Details about the Tactic DDD Syntax

    If you want to read more details about the syntax of the tactic DDD part within bounded contexts, we refer to the Sculptor documentation.

    Improve this page on GitHub
    ← PreviousAggregate Next →Application and Process Layer
    © 2026 Context Mapper contributors
    • GitHub
    • Get Involved
    • Background & Publications
    • RSS