Actors can rule your DDD world
summary
A homemade shipping app called beerSender.net handles real-world UPS customs failures and uses .NET 6 with Akka.NET to model each DDD aggregate as a persistent actor with a unique persistence id, snapshotting (example: every 100 events) and the persist()/recover lifecycle. Commands flow through a command router that can be a pool with consistent hashing to shard aggregates, while projector actors subscribe to the event stream to update read stores; claimed throughput is millions of messages per second.
AI-written summary · about
chapters (27)
- 0:00Intro
- 1:12Lockdown boredom
- 2:19Reality
- 3:18Sending beer is tricky
- 4:04DDD in a nutshell
- 6:11Commands & Events
- 9:33What I want
- 13:16The simplest actor
- 15:00The Actor System
- 17:17Actor hierarchy
- 17:52Creating Children
- 21:42Supervision
- 29:20Aggregates
- 29:42Base behavior
- 30:36Implementation (State)
- 31:10Implementation (Commands)
- 31:55Implementation (Events)
- 32:39Test base class (1)
- 34:03Clean Test
- 35:45Aggregate Actor
- 36:04Base Actor (3)
- 40:22Aggregate manager
- 42:20Command Router
- 44:27Projectors
- 45:38Fold the event stream
- 48:33Inbox overflow
- 53:36Things we didn't talk about
related talks
01h 00mReactive DDD—When Concurrent Waxes Fluent
45mEverything is an Actor
58mReactive DDD—When Concurrent Waxes Fluent
58mWelcome to the (state) machine
54mBuilding personalization with Orleans and Actor Modelling
48mThe Zen of Akka
25mArchitecting Web Apps - Lights, Camera, Action!
59mSucceeding at Reactive Architecture