Update README.md

Author: jerowork

README.md

@@ -15,17 +15,17 @@ _From "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Er
 However, Event Sourcing with DCB has some advantages/solves some pitfalls over a traditional aggregate setup.
 
 ### Reusable domain events
-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. 
-However, the DCB pattern removes this restriction by treating domain events as _pure events_.
+In traditional event sourcing (if we call it like that already 😛), there’s usually a strict one-to-one relation between an aggregate and a domain event, 
+which helps keep things internally consistent within each aggregate. The DCB pattern takes a different approach by loosening this rule and treating domain events as so-called _pure events_.
 
-This shift allows us to develop business decision models using specific subsets of domain events, even when they span across multiple domain identities.
+This opens up new possibilities for building business decision models based on selected domain events, 
+also when these events spread across different domain identities.
 
-This approach aligns well with how [EventStorming](https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet) currently conceptualizes aggregates. 
-In EventStorming, these are often referred to as "systems" or "consistent business rules" 
-rather than “aggregates” to make the concept more accessible to non-technical participants in the design process. 
+This approach lines up well with how [EventStorming](https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet) looks at aggregates. 
+In EventStorming, what we typically call aggregates is nowadays be seen as "systems" or "consistent business rules", making the concept easier to grasp for non-technical actors involved in design.
 
-Replacing aggregates with business decision models through the DCB pattern mirrors EventStorming’s focus on "business rules",
-bringing the software design closer to the problem space and reducing accidental complexity that can arise from translating to a purely technical aggregate concept.
+So, by replacing aggregates with business decision models with the DCB pattern, we’re aligning more closely with EventStorming’s focus on "business rules".
+This brings our design closer to the actual problem space and avoids so-called _accidental complexity_ that is introduced with the translation to aggregates.
 
 ### No aggregate synchronisation nor domain services needed
 As a domain event can be used by multiple business decision models, there is no synchronization needed between aggregates.