Event-Sourcing basic example app
Aim: learn basics of event sourcing pattern and its caveats.
This project builds on an example from the presentation from Mathias Verraes - Practical Event Sourcing.
Learning DDD (Domain Driven Design)
Bellow is learning material that I have used to dive into event DDD (and its implementations) deeper.
The Strategic Design
I have put DDD in its own section because DDD is more an analysis process than a collection of structural patterns.
- Eric Evans: InfoQ: Strategic Design (Flash needed)
-
book: Eric Evans: Domain-Driven Design - Tacking Complexity in the Heart of Software (book; read especially bounded context capture)
- Eric Evans: Tackling Complexity in the Heart of Software (10 years later; explains how to read his book) DDD Europe 2016
- Eric Evans: Good Design is Imperfect Design (the big thing; lot of very good observations) DDD Europe 2017
- David West: The Past and Future of Domain-Driven Design (How computing evolved into what it is now; very interesting)
- Jimmy Bogard: Domain Driven Design: The Good Parts
- Jimmy Bogard: Crafting Wicked Domain Models
- Greg Young: A Decade of DDD, CQRS, Event Sourcing DDD Europe 2016
Case studies
The Technical Stuff
This section describes how people are implementing their domains. Be careful. Always make sure you know why author of talk decided to do his thing that way.
Cannot stress enough that DDD does NOT have just a technical part. It is more style of thinking that you need to learn by shifting you mind. (see the first section of this document)
Keep it simple
Event Sourcing + CQRS
An alternative implementation of domain model persistence layer which stores a complete history of all events that happened in the domain in the past.
-
lightning talk: Mountain West Rubyconf 2010 - Alistair Cockburn - CQRS
-
Greg Young's Event sourcing class + Greg Yong's CQRS documents (circa overview of course)
-
Querying Event Streams (wow!)
-
Greg Young's full and up-to-date DDD/CQRS/EventSourcing class
-
Mathias Verraes' elaborate on domain events - Domain Events allow you to segregate the models of different systems
-
Tip: Try to watch some microservices/stream processing videos. There are surprising similarities.
(The structural part of) DDD in PHP
- William Durand: DDD with Symfony2:
- Jan Kuchar's second sandbox
- DDDinPHP
Message Buses/libraries
-
Prooph (cool one!)
- super flexible
- library: the ability to mix&match
- well designed
- support for snapshotting
- unfortunately does not support Sagas yet! (contribution?)
- up-casting is strange: why it is not JIT up-cast? http://getprooph.org/event-store/upcasting.html
- Nested transaction? http://getprooph.org/event-store-bus-bridge/transaction_manager.html
-
broadway
- feature richer
- you have to use all (single package)
- more like a framework than library (overkill?)
- looks like a some's project by product
- experimental support for process managers
- Predaddy
- EventCentric.Core
- litecqrs-php
-
Buttercup.Protects - A PHP library for building Aggregates that protect business invariants, and that record Domain Events.
- Nice explanation of event-sourcing principles on a richly commented simple example code.
Process Managers / Sagas (the same thing!)
- Jonathan Oliver: Sagas with Event Sourcing - first part, second part
- Jonathan Oliver: Sagas, Event Sourcing, and Failed Commands
- Udi Dahan: Saga Persistence and Event-Driven Architectures
Examples
- Mathias Verraes: Buttercup.Protects is a PHP library for building Aggregates that protect business invariants, and that record Domain Events.
- EventSourcing at BlaBlaCar + Matthieu Moquet: CQRS & Event Sourcing
- GitHub: example applications written with CQRS/event sourcing pattern
Notes / TODOs
-
How to make a proper relation between Product and Basket?
- Answer: Analyse bounded contexts. (probably in most domains use two separate AggregateRoots)
-
How to access product name when product-related event occurs - aggregate does not expose any state?! (should I access read model from write model?)
- Answer: Access read side if needed or use heavy events.
-
If aggregate produces event but it does not change state in any way, should it have empty apply() method for this event or should framework just skip this event. (this can lead into hard discoverable typo errors)
- Answer: I would prefer to hot have this methods in aggregate and have some kind of static analysis check for method name and type consistency (in PHP which does not support method overloading).
-
Is there any point of adding events when loading from history into the object "recorded events"?
- Answer: No, if you load them there, they will be persisted once more and there will be a need for merge process.