Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 15 additions & 0 deletions _docs/language-reference/bounded-context.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,7 @@ BoundedContext CustomerManagementContext implements CustomerManagementDomain {
domainVisionStatement = "The customer management context is responsible for ..."
implementationTechnology = "Java, JEE Application"
responsibilities = "Customers", "Addresses"
nonResponsibilities = "Policies", "Debt collection"
knowledgeLevel = CONCRETE

Module addresses {
Expand Down Expand Up @@ -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/).

### 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"
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 _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:
* CONCRETE
Expand Down
2 changes: 1 addition & 1 deletion _docs/language-reference/responsibility-layers.md
Original file line number Diff line number Diff line change
Expand Up @@ -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 _nonResponsibilities_ keyword (see [Bounded Context](/docs/bounded-context/#non-responsibilities)):

```cml
BoundedContext CustomerManagementContext implements CustomerManagementDomain {
Expand Down
Loading