Bounded Context

Bounded contexts are defined on the root level of a CML (*.cml) file and then referenced on a context map which defines the relationships with other bounded contexts. Have a look at context map to see how you add a bounded context to your context map.

Syntax

The following example illustrates how a bounded context is defined in CML (syntactical features). The Customer Management context is a context within our fictitious insurance company example. The whole example with the context map and all bounded contexts can be found here.

BoundedContext CustomerManagementContext implements CustomerManagementDomain {
  type = FEATURE
  domainVisionStatement = "The customer management context is responsible for ..."
  implementationTechnology = "Java, JEE Application"
  responsibilities = "Customers", "Addresses"
  knowledgeLevel = CONCRETE

  Module addresses {
    Aggregate Addresses {
      Entity Address {
        String city
      }
    }
  }
  Aggregate Customers {
    Entity Customer {
      aggregateRoot

      - SocialInsuranceNumber sin
      String firstname
      String lastname
      - List<Address> addresses
    }
  }
}
Note: Bounded Context names must be unique within your CML model.

With the implements keyword you specify which domain or subdomains are implemented by this bounded context. After the implements keyword you can either reference a list of subdomains (comma-separated) or one complete domain. See Subdomain to learn how subdomains are specified.

The equal sign (=) to assign attribute values is optional and can be omitted. Attribute values are then assigned as follows:

BoundedContext ContextMapperTool refines StrategicDomainDrivenDesignContext {
  type FEATURE
  domainVisionStatement "Context Mapper provides a formal way to model strategic DDD Context Maps."
  implementationTechnology "Java, Eclipse"
}

The example above further shows how you can refine another bounded context with the refines keyword. This feature allows you to create some kind of an inheritance hierarchy in case one bounded context can be seen as a refinement of another bounded context. However, note that this is only a modeling information and generators do not recursively resolve the domain model (Aggregates, etc.) of refined bounded contexts.

All of the following attributes are optional and you do not have to specify them all.

Bounded Context Type

With the type keyword you define the bounded contexts type, which can be one of the following:

  • FEATURE
  • APPLICATION
  • SYSTEM
  • TEAM

The type provides an indicator for which reason a bounded context may have been evolved. It further allows you to specify from which viewpoint you describe your bounded contexts. For example you may want to create a team map, within which every bounded context reflects a team, inspired by Brandolini. A team map further allows you to specify which team is implementing which bounded contexts. Note that the context map type must be ORGANIZATIONAL to specify a team map. The corresponding syntax is described under context map and an example for a team map can be found here.

Domain Vision Statement

With the domainVisionStatement keyword you can describe the vision statement of your bounded context, according to the DDD Domain Vision Statment pattern.

Implementation Technology

The implementationTechnology attribute allows you to add information about how the corresponding bounded context is implemented.

Responsibility Layers

With the responsibilities keyword you are allowed to specify the responsibilities of the bounded context, according to the DDD Responsibility Layers pattern. See responsibility layers.

Knowledge Level

With the knowledgeLevel attribute you define the knowledge level of the bounded context which can be one of the following two:

  • CONCRETE
  • META

This attribute allow you to define the knowledge level according to the DDD Knowledge Level pattern.

Team realizes Bounded Context

If your bounded context is of the type TEAM, you can specify which bounded context the team implements by using the realizes keyword. The following example illustrates this:

BoundedContext CustomersBackofficeTeam implements CustomerManagementDomain realizes CustomerManagementContext {
  type = TEAM
  domainVisionStatement = "This team is responsible for implementing ..."
}

The Bounded Context Building Blocks

Within a bounded context you can create Modules and Aggregates, as illustrated in the example at the beginning of this page. On this tactical DDD level we integrated the Sculptor DSL. This means within a module and an aggregate you can use all the Sculptor features to specify your bounded context, such as Entities, Value Objects, Domain Events, Services, Repositories, etc.

Use the Sculptor Documentation and our examples to find out how you specify your bounded context. Note that the Aggregate pattern is the only tactical DDD pattern where we changed the Sculptor syntax and adapted it to our interpretation and requirements. See Aggregate.

Semantic Rules

Note that semantic rules (validators) exist for bounded contexts within CML. This means that not every combination of patterns and concepts is allowed, even if it would be syntactically correct. The following rules apply to a bounded context:

  • The realizes keyword of the bounded context rule can only be used if the type of the bounded context is TEAM.

For a summary of all semantic rules and justifications, please consult Language Semantics.