All Projects → ddd-crew → Aggregate Design Canvas

ddd-crew / Aggregate Design Canvas

Licence: cc-by-sa-4.0
A structured approach to designing and documenting Aggregates

Projects that are alternatives of or similar to Aggregate Design Canvas

Ddd Embeddables
A collection of reusable value objects written in PHP and targeting versions 5.6 and above.
Stars: ✭ 66 (-43.1%)
Mutual labels:  domain-driven-design
Productcontext Eventsourcing
A practical/experimental Event Sourcing application on Product Bounded Context in an e-commerce
Stars: ✭ 88 (-24.14%)
Mutual labels:  domain-driven-design
Aspnetboilerplate
ASP.NET Boilerplate - Web Application Framework
Stars: ✭ 10,061 (+8573.28%)
Mutual labels:  domain-driven-design
Event Sourcing Castanha
An Event Sourcing service template with DDD, TDD and SOLID. It has High Cohesion and Loose Coupling, it's a good start for your next Microservice application.
Stars: ✭ 68 (-41.38%)
Mutual labels:  domain-driven-design
Paris
TypeScript library for implementing Domain-Driven Design in web apps
Stars: ✭ 83 (-28.45%)
Mutual labels:  domain-driven-design
Ddd Tdd Rich Domain Model Dojo Kata
DDD patterns implemented following TDD
Stars: ✭ 91 (-21.55%)
Mutual labels:  domain-driven-design
Gamecomposer
GameComposer is a game authoring tool and also a game runtime environment targeting at desktop and mobile devices.
Stars: ✭ 59 (-49.14%)
Mutual labels:  domain-driven-design
Bifrost
This is the stable release of Dolittle till its out of alpha->beta stages
Stars: ✭ 111 (-4.31%)
Mutual labels:  domain-driven-design
Sample Dotnet Core Cqrs Api
Sample .NET Core REST API CQRS implementation with raw SQL and DDD using Clean Architecture.
Stars: ✭ 1,273 (+997.41%)
Mutual labels:  domain-driven-design
Study Path
An organized learning path about Clean Code, Test-Driven Development, Legacy Code, Refactoring, Domain-Driven Design and Microservice Architecture
Stars: ✭ 1,357 (+1069.83%)
Mutual labels:  domain-driven-design
Patterns
Complete catalog of all classical patterns in the Archimate language
Stars: ✭ 70 (-39.66%)
Mutual labels:  domain-driven-design
Typescript Event Sourcing
Domain Driven Design, Event Sourcing & Command Query Responsibility Segregation with Typescript
Stars: ✭ 83 (-28.45%)
Mutual labels:  domain-driven-design
Cargotracker
The project demonstrates how you can develop applications with Jakarta EE using widely adopted architectural best practices like Domain-Driven Design (DDD).
Stars: ✭ 93 (-19.83%)
Mutual labels:  domain-driven-design
Stepping
Stepping - a tools for code design, event storming, domain model generate.
Stars: ✭ 67 (-42.24%)
Mutual labels:  domain-driven-design
Polysemycleanarchitecture
Showcasing how the Polysemy library can be used to implement a REST application conforming to the guidelines of the Clean Architecture model.
Stars: ✭ 106 (-8.62%)
Mutual labels:  domain-driven-design
Context Mapper Examples
ContextMapper DSL: Examples
Stars: ✭ 66 (-43.1%)
Mutual labels:  domain-driven-design
Context Mapper Dsl
ContextMapper DSL: A Domain-specific Language for Context Mapping & Service Decomposition
Stars: ✭ 88 (-24.14%)
Mutual labels:  domain-driven-design
User Bundle
A new Symfony user bundle
Stars: ✭ 116 (+0%)
Mutual labels:  domain-driven-design
Comboost
ComBoost是一个领域驱动的快速开发框架
Stars: ✭ 111 (-4.31%)
Mutual labels:  domain-driven-design
Cleanarchitecture
An example of how to implement various clean coding & architecture techniques. Technologies used: .Net Core, Razor Pages, EF Core, Bootstrap 4
Stars: ✭ 98 (-15.52%)
Mutual labels:  domain-driven-design

The Aggregate Design Canvas

The Aggregate Design Canvas is a modelling tool meant to be used as a part of design-level domain modelling activities.

An aggregate is a lifecycle pattern originally described by Eric Evans. By aggregate, we understand a graph of objects that is a consistency boundary for our domain policies. Depending on the design of the aggregate we can either enforce them (make them invariant) or be forced to have corrective policies in place. Because of that it is important to design the boundaries of aggregates well, as they impact behaviours modelled within our domain.

The canvas has a suggested order of working through it, that helps to iteratively discuss different aspects of the aggregate design.

Aggregate Design Canvas

Downloads

How to Use

1. Name

Give your aggregate a good name. In some domains it makes sense to include as part of the name the length of a cycle, or some other indication of the life span of the aggregate.

2. Description

Summarise the main responsibilities and purpose of the aggregate. It’s a good idea to include the reasons why such boundaries were chosen and tradeoffs that were made compared to other designs.

3. State Transitions

Usually the aggregate goes through explicit state transitions, that impact the way it can be interacted with. Too many transitions might indicate that process boundaries weren't modelled properly and can be split. Very naive / simple transitions might indicate that the aggregate is anaemic and that logic was pushed out to services. In this section of the canvas list the possible states or draw a small transition diagram.

4. Enforced Invariants & 5. Corrective Policies

One of the main jobs of the aggregate is to enforce business invariants. These invariants protect business logic. Listing the main ones in this section will make sure that you agree on the responsibilities that the aggregate has. A large number of enforced invariants can indicate high local complexity of the aggregate implementation.

If you decide to change the boundaries of the aggregate and relax some of the invariants (for example to reduce the chance of concurrency conflict), then some extra business logic might be required to correct some of the inconsistencies. In the context of this canvas, we call this logic corrective policies. A large number of such policies might indicate that the business logic was pushed outside of the aggregate, which can increase the complexity of implementation.

Listing on the canvas both Invariants and Corrective Policies will make design trade-offs explicit and will help you decide whether the boundaries you decided on are useful or not.

6. Handled Commands & 7. Created Events

In this section you list all the commands that the aggregate is capable of handling and all events that will be created as a result. It might be a good idea to create connectors between them in order to validate that you are not missing any of the building blocks.

8. Throughput

The goal of this section is to estimate how likely a single aggregate instance is going to be involved in concurrency conflicts (when two or more competing callers try to make changes at the same time). For each metric estimate the average and maximum - it will help you to reason about the outliers as they often drive the boundary reevaluation.

The Command handling rate metric describes the rate at which the aggregate is processing new commands. On the other hand the Total number of clients says how many clients are likely to issue these commands.

To give you an example - if an aggregate models a basket on the website then it’s likely there will be only one client issuing commands to this basket. If we compare it to an aggregate that models a conference booking system then it’s likely we are going to have tens or hundreds of clients trying to book tickets.

Aggregate concurrency conflict chance evaluation chart

Aggregate concurrency conflict chance evaluation chart

Putting these metrics on a graph will give you a rough estimate of a Concurrency conflict chance, which is what we are ultimately looking for. Plotting both Avg and Max for multiple alternatives will allow you to explicitly talk about the throughput tradeoffs. Generally speaking, aiming for a small chance of conflict will deliver better customer experience, but will also increase the complexity of implementation. Or if we put it in a different way: bigger aggregates will have higher chance of concurrency conflict, but less policies to correct data.

9. Size

The last section of the canvas will help you estimate the hypothetical size of the aggregate. In this case the size itself is being measured in the number of events per aggregate instance. Depending on how you model the domain, the events might end up being fine or coarse grained, so the size of the events will also play a role.

E.g. a OrderCreated event could have multiple LineItems as part of the event, or model these line items as separate LineItemAdded events. In case of coarse grained events, the overall size of the aggregate will be bigger, even if the number of events is small.

The Event growth rate metric should estimate how many events are appended to a single aggregate instance. The Lifetime of an instance will tell us how long the instance is going to live and as a consequence how many events will be accumulated and fetched when we need to process a new command.

Aggregate size evaluation chart

Aggregate size evaluation chart

Medium and large number of events might impact the customer experience and make the command handling slow. Fortunately, in most cases this can be dealt with using snapshots. Another thing to look for are long-lived instances (potentially infinite). This might cause problems when it comes to archiving data and ever growing streams. For that reason it’s usually a good heuristic to scope the aggregate to a specific time period (e.g. billing period).

Additional Resources

Examples

Naive bank account

Aggregate Design Canvas

Contributors

Thanks to all existing and future contributors and to Mathew McLoughlin who has contributed to the Aggregate Design Canvas:

The canvas was inspired by the Bounded Context Canvas.

Contributions and Feedback

The Aggregate Design Canvas is freely available for you to use. In addition, your feedback and ideas are welcome to improve the canvas or to create new versions.

Feel free to also send us a pull request with your examples.

CC BY 4.0

This work is licensed under a Creative Commons Attribution 4.0 International License.

CC BY 4.0

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].