Platform Engineering is Domain-Driven Design
summary
Argues platform engineering must combine Domain-Driven Design with runnable architecture so platforms deliver business-specific services rather than rebranded infra; recommends building vending machine self-service flows (not ticketing), measuring success by whether users build surprising things, and exposing lane assist instead of late guardrails. Advises lifting domain concepts into platform APIs (example: a ledger database for PII/financial needs), warns that failure does not respect abstraction and that cloud compiler mappings, region limits and composability determine what can actually be built.
AI-written summary · about
chapters (15)
- 0:00The case for platforms
- 2:08Cognitive load and friction
- 4:00The double pyramid model
- 7:26Lessons from car manufacturing
- 10:03Avoiding platform anti-patterns
- 11:59Platforms as reified architecture
- 14:26Serving diverse customers
- 17:04Mindset shifts and guardrails
- 20:02Lane assist vs. guardrails
- 21:47Designing meaningful abstractions
- 25:52Abstraction and human judgment
- 30:45Intuition over API simplicity
- 34:42Domain modeling in platforms
- 40:58Footnotes on implementation
- 43:33Composability and AI impact
related talks
48mPlatform Engineering is Domain Driven Design
01mPlatform Engineering is Domain Driven Design
23mPlatform Engineering for Architects - Crafting Platforms as a Product
32mPlatform Engineering for Software Developers and Architects (Redux)
26mThe Past, the Present, and the Future of Platform Engineering
34mPlatforms: Defying the laws of IT physics
51mThe Magic of Platforms
29mPlatforms, Architecture and Sustainability