All our aggregates are wrong
summary
Argues that modeling a shopping cart as one aggregate creates tight coupling; decomposes cart into domain-owned services (sales owns cart ID, warehouse owns inventory, shipping owns estimates) and builds a composition gateway (reverse proxy that matches routes and composes a view by parallel calls) plus per-service caches (pricing cached 10 minutes, marketing 6 months). Read composition works; writes use queues, an append-only requestId ledger for idempotence and compensations. Demo is a 36-project demo showing this approach in practice.
AI-written summary · about
chapters (24)
- 0:00Intro
- 1:10Buy a "Banana Protector"
- 2:11Sounds like a nice looking aggregate
- 5:21However, availability changes over time
- 6:26Business requirements (#3)
- 9:03It's becoming messy, isn't it?
- 11:27Can we get rid of all this coupling?
- 14:01Let's decompose the Shopping Cart
- 15:34Marketing tends to be stable
- 17:33We followed the coupling
- 20:39Can Read Models be a solution?
- 22:48We cannot cache everything
- 25:15Shared identifiers
- 27:05View Model Composition (flow)
- 30:32Sales Product Requests Handler
- 30:49Sales Request matching
- 31:30Sales Composition
- 33:44View Model Decomposition
- 35:45Shipping Request Matching
- 36:06Shipping Decomposition
- 38:48Shipping Error Handling
- 44:55Full Vertical Slices
- 47:19Services communication channel
- 50:53The final big picture
related talks
50mDeveloping Microservices with Aggregates
15mArchitecting Scalable Order Management Systems with Microservices
48mThe Aggregate is dead. Long live the Aggregate!
50mThe Aggregate is dead. Long live the Aggregate!
48mThe Aggregate is dead. Long live the Aggregate!
47mGetting (service) design right
47mThe Aggregate is dead. Long live the Aggregate!
30mThe Entity Microservice Trap: You May Be Doing It Wrong