Domain and Subdomain

As bounded contexts, domains are defined on the root level of a CML (*.cml) file. They provide a container to specify all subdomains which are then referenced on a bounded context with the implements keyword. A bounded context can also implement the compete domain. Have a look at bounded context for an example.


The following example illustrates how you can specify a domain with subdomains in CML:

/* Syntax example: Domain and Subdomains */
Domain Insurance {
  domainVisionStatement = "Insurance domain vision statement ..."

  Subdomain CustomerManagementDomain {
    type = CORE_DOMAIN
    domainVisionStatement = "Subdomain managing everything customer-related."

    Entity Customer {
      String firstname
      String familyname

    /* Add more entities ... */

  Subdomain ContractManagementDomain {}

  /* Add more subdomains ... */

Note that the equal sign (=) to assign an attribute value as done in the example above is optional and can be omitted.

Subdomain Type

With the type keyword you specify of which type your subdomain is. The following types exist:


Domain Vision Statement

With the domainVisionStatement keyword you can specify a vision statement for domains and subdomains, according to the DDD Domain Vision Statement pattern.


In order to provide further details about your subdomain and which domain objects are part of it, you can use entities within a subdomain. Note that the used Entity rule is integrated from the Sculptor DSL. For more details about the features and possibilities of this Entity rule, we refer to the Sculptor documentation. An example of a simple entity with attributes is illustrated above.

Note that only entities can be used within the subdomains. It is not possible to use Aggregates or other tactic DDD concepts within them. The entities within subdomains are only used for business modeling purposes and not respected by the generator tools. Generators respect the domain model within Bounded Contexts.