High-Speed DDD (revisited)
summary
Presents concrete Domain-Driven Design patterns to move quickly without accumulating "functional debt": extract a separate VAT estimation module (with an ACL/adapter and back-office UI, later exposed to customers) to isolate tax logic and reduce support load; prefer API-on-read over duplicating events to avoid owning another service’s data lifecycle; and extract write models into dedicated datastores so the legacy invoice table becomes a read model. Also describes practical practices used in production: ~7,000 acceptance tests, RabbitMQ-style brokers, and dual-track discovery.
AI-written summary · about
chapters (8)
- 0:00Introduction
- 3:52Time to market vs functional debt
- 9:54Three patterns to survive
- 12:20Case study: VAT refunds
- 23:13Case study: debt schedule
- 30:29Case study: invoice table
- 35:37Avoiding functional debt
- 40:55Q&A
related talks
55mHigh-speed DDD
29mRethinking Domain-Driven Design in Go
59mDomain-Driven Design - Where Rubber Meets the Road
45mDon't Overdose on Domain-Driven Design
47mDomain-Driven Design: A Complete Example
55mDomain-Driven Design: back to the roots
39mLessons Learned from 10+ Years with Domain Driven Design
38mWhat I talk about when I talk about Domain Driven design