Bounded Context

Bounded Context a key concept in strategic DDD. The interpretation and usage of the pattern in Context Mapper is explained in the article “Domain-driven Architecture Modeling and Rapid Prototyping with Context Mapper”.

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
    }
  }
}

The implements keyword specifies which domain or subdomains are implemented by this bounded context. Behind the implements keyword you can either reference a list of subdomains (comma-separated) or one top-level domain. Consult Subdomain to learn how subdomains are specified.

Attribute values are 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"
}

An equal sign (=) to assign attribute values may be present but can be omitted.

The example above also shows how you can let one bounded context refine another one (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. FEATURE contexts are analysis or early design abstractions, taking a functional scenario view. Application contexts represent more elaborated, logical designs and implementation views; system contexts add a more physical, process- and deployment-oriented view.

Finally, 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 (of type FEATURE, APPLICATION, or SYSTEM). 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.

The following table lists examples for each Bounded Context type to illustrate how we interpret them:

You can evolve the different types of Bounded Context with our Rapid Object-oriented Analysis and Design CML transformations. From functional requirements written as user stories or use cases you can derive Bounded Contexts of the type FEATURE and/or APPLICATON. From those features you can then derive Bounded Contexts of the type SYSTEM automatically. You can find more about this automated transformations here.

Domain Vision Statement

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

Implementation Technology

The implementationTechnology attribute allows you to add information about how the corresponding bounded context is implemented. Note that this attribute does not correspond to any DDD pattern.

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 allows you to define the knowledge level according to the DDD Knowledge Level pattern. See this page.

Support for Bounded Context Canvases

To support Bounded Context Canvases, use these optional fields in BoundedContext:

• businessModel. Free text; common values include:
  • UNDEFINED
  • REVENUE
  • ENGAGEMENT
  • COMPLIANCE
  • COST_REDUCTION
• evolution. One of:
  • UNDEFINED
  • GENESIS
  • CUSTOM_BUILT
  • PRODUCT
  • COMMODITY

Further reading on bounded context canvases:

• The Bounded Context Canvas
• Bounded Context Canvas V3: Simplifications and Additions
• DDD re-distilled
• What I talk about when I talk about Domain-Driven Design by Andrew Harmel-Law

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.

Improve this page