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.


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 { "The addresses of a customer" }
  knowledgeLevel = CONCRETE
  Module addresses {
    Aggregate Addresses {
      Entity Address {
        String city
  Aggregate Customers {
    Entity Customer { 
      - 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 subdomain is implemented by this bounded context. See Subdomain to learn how subdomains are specified.

Note that 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:

  • 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:

  • 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.