This is a long post based on my upcoming book about Functional Event Sourcing. Not ETA yet, but I thought I still needed to publish something at some point. There is of course far more content in the book 😁
And there are probably more post that will follow
• • •
Missing some Tweet in this thread? You can try to
force a refresh
@johnbywater@SKleanthous@RagingKore That was a long interesting thread :) and there are many things to discuss here.
After discussion with Eric and other DDD practitioners, the tactical patterns are very concrete, but come from more abstract ideas.
@johnbywater@SKleanthous@RagingKore The aggregate is implemented as a class that references other entities and value objects to maintain consistency. But the more general description is that this is something that is defined by a consistency boundary. What is inside is consistent, what's outside *doesn't have to*
@johnbywater@SKleanthous@RagingKore Once this is said, an aggregate should not have to call another's method aggregate as part of it's own decision. (or they would become consistent together, and be a single aggregate).
After several discussions about event sourcing today, I think it's time to clarify things. Thread ⬇ 1/8
When talking about Query eventual consistency, views autorebuild with 0 downtime deployment, snapshots, automatic failover, we're in the Advanced Non Functional Requirements column with high availability, low latency, distributed systems, so infra is advanced and non obvious 2/8
This is normal, you cannot have high quality of service under scale and hope it will work like magic. You'll have to solve some problems, and all solutions will not be obvious. Distributed systems are hard. 3/8