Skip to content

Latest commit

 

History

History

AR-04-Extract-Aggregates-by-Volatility

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 
 
 

AR-4: Extract Aggregates by Volatility

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.

Context & Rationales

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:

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.

Goal

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:

Preconditions

  • The selected bounded context must contain at least two aggregates.
  • The aggregates of the selected bounded context must have different likelihoods for change.

Input

  • One bounded context.

Output

  • Another bounded context containing all the aggregates with the selected volatility.

Example

The following two CML snippets show an example input and output illustrating how this AR works.

Input

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

Output

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 Sources

Further documentation