Reactive DDD—When Concurrent Waxes Fluent
summary
Argues that using Vlingo (Java/.NET) with the actor model and a fluent completes with API produces non‑blocking, type‑safe Domain‑Driven Design; shows a proposal actor that’s event‑sourced and keeps a progress state to handle indeterminate pricing, scheduling, and staffing verifications. Recommends strangling a legacy monolith via transaction‑log listeners or triggers (Oracle GoldenGate) into a CQRS query model. Warns splitting 2M lines into 100‑line services yields ~20,000 services (~$96M/year at $400/mo each) and prefers well‑modularized monoliths before microservices.
AI-written summary · about
chapters (33)
- 0:00Reactive DDD When Concurrent Waxes Fluent
- 1:52Reactive Platform Chief Architect
- 6:11Inefficient
- 8:28Anemic Domain Model
- 10:07Inarticulate
- 16:23Reactive message-driven
- 18:49Event Driven
- 22:42Fluent?
- 22:54Completes
- 25:27Not a Noun?
- 26:17Protocol
- 26:45Fluent Model
- 27:36Fluent API
- 28:46Fluent Inside
- 29:32Reactive?
- 29:50Type Safe?
- 30:34Uncertainty (1)
- 32:20Model It
- 38:22Business Wants
- 39:09Legacy: Monolith
- 39:34Legacy: BBOM
- 41:12Dependencies?
- 42:38Complex System
- 43:54Bounded Context
- 45:59Tell!
- 46:32Explicit, Testable, Less Code
- 47:25Monolith to Microservices
- 48:20Eat an Elephant One bite at a time.
- 49:43Strangler (2)
- 51:57Restructured (1)
- 53:35Reactive Rework
- 54:05Architecture
- 54:27Open Source Reactive Platform
related talks
58mReactive DDD—When Concurrent Waxes Fluent
45mUsing DDD To Decompose Your Monolith
40mMicroservices without DDD is risky business!
45mBuilding Monoliths that Could Scale (Easily) to Microservices (If They Need)
49mDDD & Microservices: At Last, Some Boundaries!
52mBuilding monolith applications that could scale to microservices..
54mReacting to an Event-Driven World
34mThe Road to a Distributed Application, or the Pitfalls of CQRS/DDD