Setup readme - added Background explaining this library

README.md

@@ -2,8 +2,11 @@
 [![Software License](https://img.shields.io/badge/license-MIT-brightgreen.svg?style=flat)](LICENSE)
 [![PHP Version](https://img.shields.io/badge/php-%5E8.3-8892BF.svg?style=flat)](http://www.php.net)
 
-> Work in progress
+_Let go of the Aggregate - EventSourcing in PHP with the Dynamic Consistency Boundary (DCB) pattern._
 
-Let go of the Aggregate - EventSourcing in PHP with DCB (Dynamic Consistency Boundary).
-
-Implementation of an event store based on the example project [Example Event Sourcing DCB PHP](https://github.com/GemberPHP/example-event-sourcing-dcb-php).
+- [Background](/docs/background.md)
+- Installation
+- Library architecture
+- A simple example
+- Library reference
+- Hooking into the library

docs/background.md

@@ -0,0 +1,64 @@
+## Background
+PHP has some nice libraries available for event sourcing, like [Broadway](https://github.com/broadway), [EventSauce](https://github.com/EventSaucePHP), [Prooph](https://github.com/prooph) and [Ecotone](https://github.com/ecotoneframework).
+They all have the "aggregate" as the primary citizen of event sourcing,
+with a strict one-to-one relation between a domain event and the aggregate.
+
+In a 'traditional' event sourced application, aggregates have strict boundaries,
+meaning that it disallows re-using domain events by multiple different aggregates.
+A common rule in event sourcing is that all business logic belonging to an aggregate should reside within that aggregate.
+
+Also, since aggregates are consistent internally, each behavioral change to an aggregate locks other behavioral changes
+(called optimistic locking), even if the changes aren’t really related from a domain perspective.
+
+An aggregate as described by Evans in his 'blue book':
+
+> Cluster the ENTITIES and VALUE OBJECTS into AGGREGATES and define boundaries around each.
+> Choose one ENTITY to be the root of each AGGREGATE, and control all access to the objects inside the boundary through the root.
+> Allow external objects to hold reference to the root only.
+
+_From "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans (the 'blue book')._
+
+However, over time, this often leads to "fat aggregates" (the new fat controller? 😛).
+
+Also, the aggregate is a highly technical concept, which makes it difficult to explain to non-technical stakeholders,
+e.g. during EventStorming sessions.
+
+## Gember Event Sourcing
+Gember addresses these issues and takes a different approach, by using a new concept called "Dynamic Consistency Boundary" (DCB) pattern in mind.
+
+**Gember Event Sourcing is still in the experimental stage, exploring how the DCB pattern works in practice.**
+
+## The Dynamic Consistency Boundary (DCB) pattern
+Introduced by Sara Pellegrini in 2023, the DCB pattern rethinks the traditional approach in event sourcing,
+which she explains well in her talk: ["The Aggregate is dead. Long live the Aggregate!"](https://sara.event-thinking.io/2023/04/kill-aggregate-chapter-1-I-am-here-to-kill-the-aggregate.html) (a must-read).
+
+In a nutshell, the DCB pattern removes the strict one-to-one relation between an aggregate and a domain event.
+As a consequence, a domain event can now be reused by multiple different aggregates, or better called now, "business decision models".
+This allows us to create business decision models based on a subset of domain events,
+or even on domain events from different aggregates, or better called now, "domain identifiers".
+
+This aligns well with the way [EventStorming](https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet) looks at aggregates nowadays.
+What they used to call aggregates are often seen as "systems" or "consistent business rules",
+making the problem space more understandable to non-technical stakeholders.
+
+With domain events now sharable across multiple different business decision models, synchronization between aggregates is no longer necessary.
+This means that e.g. domain services, which are usually created to manage business logic across aggregates, are not needed anymore.
+Similarly, "sagas", when used to subscribe to events in order to synchronize between aggregates, are also no longer necessary.
+
+Replacing "fat aggregates" with multiple business decision models also resolves consistency issues (optimistic locking)
+between behavioral changes that seem unrelated from a domain point of view.
+A business decision model is consistent only for the specific subset of domain events relevant to its domain identifier.
+
+> For example, splitting into different business decision models allows behavioral changes to a course title
+> without blocking a student from subscribing to that course (referring to Sara Pellegrini’s example).
+
+Overall, the DCB pattern reduces the "accidental complexity" introduced by aggregates, letting us build software that better reflects the real world.
+
+**More information about the DCB pattern:**
+
+_"Kill the aggregate!"_ - Sara Pellegrini, Milan Savic, 2023
+- Blog: https://sara.event-thinking.io/2023/04/kill-aggregate-chapter-1-I-am-here-to-kill-the-aggregate.html
+- Talk: https://www.youtube.com/watch?v=wXt54BawI-8
+
+_"Rethinking microservices architecture through Dynamic Consistency Boundaries"_ - Bruce Hopkins, 2024
+- Blog: https://www.axoniq.io/blog/rethinking-microservices-architecture-through-dynamic-consistency-boundaries