Splits a bounded context by grouping those aggregates together into one bounded context which belong to the same team.
Hint: An aggregate in CML can belong to one owner/team (therefore the singular owner in the AR name).
By decomposing a system into multiple bounded contexts we aim for loose coupling between the bounded context and a high cohesion within them. One approach to achieve this and to decompose a system into components or (micro-) services is to split by owner (team).
See also:
- Coupling criterion Shared Owner of ServiceCutter
- Conway's Law
- "Bounded contexts decouple PARTS. Parts are code and teams." by Nick Tune
In Context Mapper you can assign an aggregate the owning team. Consult our aggregate documentation page to see how this can be modeled in CML.
This Architectural Refactoring (AR) splits a bounded context by the owners of the aggregates. This means, it creates bounded contexts containing aggregates which all belong to the same team. It can be applied if your model exhibits a bounded contexts with aggregates which are owned by different teams.
Inverse AR's:
- The bounded context must contain at least two aggregates.
- The aggregates must be assigned to different teams.
- One bounded context.
- The AR creates multiple bounded contexts. Each bounded context contains one or more aggregates which are owned by the same team.
The following two CML snippets show an example input and output illustrating how this AR works.
The following bounded context contains two aggregates which are owend by two different teams:
/* With a right-click on the 'CustomerSelfServiceContext' bounded context you can execute the 'Split Bounded Context by Owners' refactoring.
* It will split the existing bounded context according to the two owning teams 'CustomerBackendTeam' and 'CustomerFrontendTeam'.
*/
BoundedContext CustomerSelfServiceContext implements CustomerManagementDomain {
type = APPLICATION
domainVisionStatement = "This context represents a web application which allows the customer to login and change basic data records like the address."
responsibilities = "AddressChange"
implementationTechnology = "PHP Web Application"
Aggregate CustomerFrontend {
owner = CustomerFrontendTeam
DomainEvent CustomerAddressChange {
aggregateRoot
- UserAccount issuer
- Address changedAddress
}
}
Aggregate Acounts {
owner = CustomerBackendTeam
Entity UserAccount {
aggregateRoot
String username
- Customer accountCustomer
}
}
}
Applying the AR Split Bounded Context by Owner produces two bounded contexts, one for each team:
BoundedContext CustomerSelfServiceContext implements CustomerManagementDomain {
domainVisionStatement = "This context represents a web application which allows the customer to login and change basic data records like the address."
type = APPLICATION
responsibilities = "AddressChange"
implementationTechnology = "PHP Web Application"
Aggregate CustomerFrontend {
owner = CustomerFrontendTeam
DomainEvent CustomerAddressChange {
aggregateRoot
- UserAccount issuer
- Address changedAddress
}
}
}
/**
* The new bounded context created by the 'Split Bounded Context by Owners' refactoring applied to 'example-input.cml'.
*
* Note that the refactoring does not produce meaningful bounded context names. You can use the 'Rename Element' refactoring (SHIFT-ALT-R)
* to rename the new aggregate.
*
* The automated refactorings add newly created bounded contexts at the end of the 'bounded context' block, which might not always be the
* desired order. You may change the order after the refactoring manually.
*/
BoundedContext NewBoundedContext1 {
Aggregate Acounts {
owner = CustomerBackendTeam
Entity UserAccount {
aggregateRoot
String username
- Customer accountCustomer
}
}
}
- Example input source: example-input.cml
- Example output source: example-output.cml