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.
gitlab.grifart.cz repo github mirror
Bellow is learning material that I have used to dive into event DDD (and its implementations) deeper.
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)
- Greg Young: Bounded Contexts (great one!)
- 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
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)
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 (5 mins and everything important!)
- Eric Evans Interviews Greg Young on the Architecture of a Large Transaction System (probably the first interview on event sourcing)
- Greg Young's Event sourcing class + Greg Yong's CQRS documents (circa overview of course)
- Querying Event Streams (wow!)
- SzymonPobiega's DDD reading list
- 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
- unknown's Domain Driven Design Through Onion Architecture
- community: CQRS.nu
- community: DDD Community
- Tip: Try to watch some microservices/stream processing videos. There are surprising similarities.
- William Durand: DDD with Symfony2:
- Jan Kuchar's second sandbox
- DDDinPHP
- Cargo example in PHP from Eric Evans blue book
- Event Sourced Rapid Application Development
- 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
- Nice showcase of important things in Prooph 7
- 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.
- 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
- 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
- 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.