Skip to content

Commit 4d2bf9f

Browse files
authored
Update README.md
1 parent 3f70bd1 commit 4d2bf9f

File tree

1 file changed

+6
-7
lines changed

1 file changed

+6
-7
lines changed

README.md

Lines changed: 6 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -15,14 +15,13 @@ _From "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Er
1515
However, Event Sourcing with DCB has some advantages/solves some pitfalls over a traditional aggregate setup.
1616

1717
### 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.
2020

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.
2222

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.
2625

2726
### No aggregate synchronisation nor domain services needed
2827
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
7069
Or run the demo command to run random sets of commands automatically:
7170
```
7271
bin/console gember:demo
73-
```
72+
```

0 commit comments

Comments
 (0)