Tutorial 5: Defining Business Logic Workflows as Domain Models :: Aggregates
Domain modelling here is the process of taking a workflow diagram and defining attributes that tell Visual Studio the intent of objects and data like properties and data types.
The core of any domain driven designed software is its aggregates. Aggregates based on the CQRS platform have methods that respond in-directly to incoming commands, later on we'll discuss how and why they respond indirectly and not directly. Aggregates can be thought of as micro-services, or at-least their methods can be. Just looking at our diagram from step 2, you can see how each step is extremely small and light weight, making any operation (box in the diagram) able to be scaled or throttled individually. In the case of this tutorial there's little more than a condition check (an if statement), creating an event and sending it. Lots of little operations like this enable your software to operate at hyper-scale levels.
Referring back to our diagram from step 2, we have two aggregates:
- Atm
- Account
- Create classes for each aggregate in the
Modulepackage itself. - Apply the
Aggregate Rootstereotype.
The Aggregate Root stereotype has many properties. Many of the properties enable automated features for CRUD based operations. These include:
- BuildACreateCommand
- BuildACreateServiceMethod
- BuildADeleteCommand
- BuildADeleteServiceMethod
- BuildAnUpdateCommand
- BuildAnUpdateServiceMethod
Other non-CRUD based properties are:
- BuildADataStore
- BuildARepository
- BuildAService
- IsSnapshotable
For this example we will not be doing CRUD based operations as this is a domain driven system... not a CRUD system. For this reason set all of those properties to false.
A datastore is the class responsible for persisting viewstate, a concept we'll be discussing later on. We'll be needing a datastore so leave this option enabled.
A repository is the class responsible for querying viewstate, this follows the standard repository pattern. We'll be needing a repository so leave this option enabled.
A service is the class responsible for providing a S.O.A. pattern over the command based nature of CQRS systems. This provides a much more family pattern for developers and third parties to work with, such as WCF and WebAPI endpoints. We'll be needing a service so leave this option enabled.
