Extracts all aggregates from a bounded context by a given volatility, or likelihood for change (RARELY, NORMAL or OFTEN), and moves them to a separate context.
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 of decomposing components is to isolate parts which are likely to change.
See also:
- Coupling criterion Structural Volatility of ServiceCutter
- On the criteria to be used in decomposing systems into modules by D. L. Parnas
In the Context Mapper DSL you can specify how often an aggregate changes with the likelihoodForChange attribute. See our page aggregate documentation page for more details.
This Architectural Refactoring (AR) extracts all aggregates with a given volatility which is provided as input parameter (RARELY, NORMAL or OFTEN) and moves those aggregates into a new bounded context. Thereby you are able to isolate aggregates with a certain likelihood for change in one bounded context. This AR can be applied if your model exhibits a bounded context with aggregates which have different likelihoods for change.
Inverse AR's:
- The selected bounded context must contain at least two aggregates.
- The aggregates of the selected bounded context must have different likelihoods for change.
- One bounded context.
- Another bounded context containing all the aggregates with the selected volatility.
The following two CML snippets show an example input and output illustrating how this AR works.
The following bounded context contains two aggregates with different likelihoods for change:
/* With a right-click on the 'CustomerSelfServiceContext' bounded context you can execute the 'Extract Aggregates by Volatility'
* refactoring. If you choose the volatility 'OFTEN', it will extract the volatile 'CustomerFrontend' aggregate and create a new bounded context for it.
*/
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 {
likelihoodForChange = OFTEN
DomainEvent CustomerAddressChange {
aggregateRoot
- UserAccount issuer
- Address changedAddress
}
}
Aggregate Acounts {
Entity UserAccount {
aggregateRoot
String username
- Customer accountCustomer
}
}
}
Applying the AR Extract Aggregates by Volatility with the volatility parameter OFTEN produces another bounded context containing the CustomerFrontend aggregate:
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 Acounts {
Entity UserAccount {
aggregateRoot
String username
- Customer accountCustomer
}
}
}
/**
* The extracted bounded context after applying 'Extract Aggregates by Volatility'
* to 'example-input.cml'. The chosen volatility was 'OFTEN'.
*
* You may want to change the name of newly created bounded contexts after applying refactorings.
*/
BoundedContext CustomerSelfServiceContext_Volatility_OFTEN {
Aggregate CustomerFrontend {
likelihoodForChange = OFTEN
DomainEvent CustomerAddressChange {
aggregateRoot
- UserAccount issuer
- Address changedAddress
}
}
}
- Example input source: example-input.cml
- Example output source: example-output.cml