You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+6-7Lines changed: 6 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,14 +15,13 @@ _From "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Er
15
15
However, Event Sourcing with DCB has some advantages/solves some pitfalls over a traditional aggregate setup.
16
16
17
17
### Reusable domain events
18
-
Traditionally, a defined boundary enforces a strict 1-on-1 relation between an aggregate and a domain event.
19
-
This makes the aggregate internally consistent. The DCB pattern removes this strict 1-on-1 relation. Instead, a domain event is considered as a _Pure event_.
18
+
In traditional event sourcing design, there's typically a strict one-to-one relationship between an aggregate and a domain event, which keeps the aggregate internally consistent.
19
+
However, the DCB pattern removes this restriction by treating domain events as pure events.
20
20
21
-
This allows us to create business decision/domain models based on a **subset of specific domain events** as well as from **multiple domain identities**.
21
+
This shift allows us to develop business decision models or domain models using specific subsets of domain events, even when they span across multiple domain identities.
22
22
23
-
These business decision models fit very well in how [EventStorming](https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet) considers aggregates currently.
24
-
Instead of aggregates, in EventStorming, these are now called 'system' or 'consistent business rule',
25
-
as the term 'aggregate' is difficult to explain for non-technical actors in a software design process.
23
+
This approach aligns well with how EventStorming currently conceptualizes aggregates. In [EventStorming](https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet), these are often referred to as “systems” or “consistent business rules”
24
+
rather than “aggregates” to make the concept more accessible to non-technical participants in the design process.
26
25
27
26
### No aggregate synchronisation nor domain services needed
28
27
As a domain event can be used by multiple business decision models, there is no synchronization needed between aggregates.
@@ -70,4 +69,4 @@ bin/console gember
70
69
Or run the demo command to run random sets of commands automatically:
0 commit comments