From 0e02928ce079b6538fc340fff94c04d551e3e0da Mon Sep 17 00:00:00 2001 From: Stefan Kapferer Date: Mon, 19 Oct 2026 22:35:07 +0200 Subject: [PATCH 1/2] Document notResponsibleFor attribute on Bounded Contexts Documentation for ContextMapper/context-mapper-dsl#372. --- _docs/language-reference/bounded-context.md | 15 +++++++++++++++ _docs/language-reference/responsibility-layers.md | 2 +- 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/_docs/language-reference/bounded-context.md b/_docs/language-reference/bounded-context.md index f6de54c..271e541 100644 --- a/_docs/language-reference/bounded-context.md +++ b/_docs/language-reference/bounded-context.md @@ -16,6 +16,7 @@ BoundedContext CustomerManagementContext implements CustomerManagementDomain { domainVisionStatement = "The customer management context is responsible for ..." implementationTechnology = "Java, JEE Application" responsibilities = "Customers", "Addresses" + notResponsibleFor = "Policies", "Debt collection" knowledgeLevel = CONCRETE Module addresses { @@ -98,6 +99,20 @@ The _implementationTechnology_ attribute allows you to add information about how ### 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](/docs/responsibility-layers/). +### Not Responsible For +With the _notResponsibleFor_ keyword you can state explicitly what the bounded context is **not** responsible for. Like _responsibilities_, the attribute takes a comma-separated list of strings: + +```cml +BoundedContext TicketSales implements FareSales { + responsibilities = "Selling fare products", "Refunds" + notResponsibleFor = "Gate validation", "Support cases" +} +``` + +Stating what is out of scope makes the boundary of a context explicit. This helps people as well as coding agents that read your model: they should not implement something in a context that the model explicitly excludes. + +When two bounded contexts are merged with the [Merge Bounded Contexts](/docs/ar-merge-bounded-contexts/) refactoring, the _notResponsibleFor_ lists are merged as well. Entries that are a responsibility of the merged context are removed. + ### Knowledge Level With the _knowledgeLevel_ attribute you define the knowledge level of the bounded context which can be one of the following two: * CONCRETE diff --git a/_docs/language-reference/responsibility-layers.md b/_docs/language-reference/responsibility-layers.md index 8f51726..c27432a 100644 --- a/_docs/language-reference/responsibility-layers.md +++ b/_docs/language-reference/responsibility-layers.md @@ -6,7 +6,7 @@ permalink: /docs/responsibility-layers/ The Responsibility Layers pattern from the ["blue book"](https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215) can be used on bounded contexts and aggregates to specify their responsibilities. ## Syntax -The responsibilities can simply be defined with the keyword/attribute _responsibilities_ and a list of responsibilities (as strings): +The responsibilities can simply be defined with the keyword/attribute _responsibilities_ and a list of responsibilities (as strings). On bounded contexts, you can additionally declare what the context is **not** responsible for with the _notResponsibleFor_ keyword (see [Bounded Context](/docs/bounded-context/#not-responsible-for)): ```cml BoundedContext CustomerManagementContext implements CustomerManagementDomain { From a8e4ef2843753d37ef52e584b5bd928ecbc151d4 Mon Sep 17 00:00:00 2001 From: Stefan Kapferer Date: Tue, 20 Oct 2026 10:59:48 +0200 Subject: [PATCH 2/2] Rename notResponsibleFor to nonResponsibilities --- _docs/language-reference/bounded-context.md | 10 +++++----- _docs/language-reference/responsibility-layers.md | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/_docs/language-reference/bounded-context.md b/_docs/language-reference/bounded-context.md index 271e541..287d778 100644 --- a/_docs/language-reference/bounded-context.md +++ b/_docs/language-reference/bounded-context.md @@ -16,7 +16,7 @@ BoundedContext CustomerManagementContext implements CustomerManagementDomain { domainVisionStatement = "The customer management context is responsible for ..." implementationTechnology = "Java, JEE Application" responsibilities = "Customers", "Addresses" - notResponsibleFor = "Policies", "Debt collection" + nonResponsibilities = "Policies", "Debt collection" knowledgeLevel = CONCRETE Module addresses { @@ -99,19 +99,19 @@ The _implementationTechnology_ attribute allows you to add information about how ### 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](/docs/responsibility-layers/). -### Not Responsible For -With the _notResponsibleFor_ keyword you can state explicitly what the bounded context is **not** responsible for. Like _responsibilities_, the attribute takes a comma-separated list of strings: +### Non-Responsibilities +With the _nonResponsibilities_ keyword you can state explicitly what the bounded context is **not** responsible for. Like _responsibilities_, the attribute takes a comma-separated list of strings: ```cml BoundedContext TicketSales implements FareSales { responsibilities = "Selling fare products", "Refunds" - notResponsibleFor = "Gate validation", "Support cases" + nonResponsibilities = "Gate validation", "Support cases" } ``` Stating what is out of scope makes the boundary of a context explicit. This helps people as well as coding agents that read your model: they should not implement something in a context that the model explicitly excludes. -When two bounded contexts are merged with the [Merge Bounded Contexts](/docs/ar-merge-bounded-contexts/) refactoring, the _notResponsibleFor_ lists are merged as well. Entries that are a responsibility of the merged context are removed. +When two bounded contexts are merged with the [Merge Bounded Contexts](/docs/ar-merge-bounded-contexts/) refactoring, the _nonResponsibilities_ lists are merged as well. Entries that are a responsibility of the merged context are removed. ### Knowledge Level With the _knowledgeLevel_ attribute you define the knowledge level of the bounded context which can be one of the following two: diff --git a/_docs/language-reference/responsibility-layers.md b/_docs/language-reference/responsibility-layers.md index c27432a..a05fbb1 100644 --- a/_docs/language-reference/responsibility-layers.md +++ b/_docs/language-reference/responsibility-layers.md @@ -6,7 +6,7 @@ permalink: /docs/responsibility-layers/ The Responsibility Layers pattern from the ["blue book"](https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215) can be used on bounded contexts and aggregates to specify their responsibilities. ## Syntax -The responsibilities can simply be defined with the keyword/attribute _responsibilities_ and a list of responsibilities (as strings). On bounded contexts, you can additionally declare what the context is **not** responsible for with the _notResponsibleFor_ keyword (see [Bounded Context](/docs/bounded-context/#not-responsible-for)): +The responsibilities can simply be defined with the keyword/attribute _responsibilities_ and a list of responsibilities (as strings). On bounded contexts, you can additionally declare what the context is **not** responsible for with the _nonResponsibilities_ keyword (see [Bounded Context](/docs/bounded-context/#non-responsibilities)): ```cml BoundedContext CustomerManagementContext implements CustomerManagementDomain {