Disposable Code, Durable Domain: Missing Layer of SDD

Developer Summit 2026

Transcript

1. The Missing Layer Of SDD Disposable Code, Durable Domain Alper Hankendi@Hepsiburada Head Of Technology
2. ~/your-system $ rm -rf src/ How would you prove the new code is correct? 2
3. Part 1 · The constraint flipped What is your asset? What would you never let anyone delete? 3
4. Why we said “code” Organizations exist to solve problems and deliver a service. The solution was always the asset. Code never was. produce keep Code was expensive to produce and cheap to keep. expensive cheap 4
5. “The system is the asset.” “The implementation is a cache.” Chad Fowler produce cheap now keep the cost Every line you keep is a line you must maintain, understand and verify. Forever. Patch it, and it becomes legacy. Regenerate it, and it stays immutable (Phoenix Architecture): features nobody uses don’t survive the next build. The System Is the Asset · Evaluations Are the Real Codebase · “code is more clearly a liability” 5
6. The Deletion Test Name one thing you’d need to rebuild it that the spec doesn’t say. spec.md login.ts Users log in with email and password. email.toLowerCase() lives only here 6
7. Fear is a signal “Code becomes asset when it is the only place knowledge lives.” 7
8. Isn’t this irresponsible? Shift Displaced What it looked like, what it was Dynamic languages Static type systems “widely criticized as undisciplined” Extreme Programming Phase-gate development “From the outside, what we were doing looked reckless.” Continuous deployment Release management “demands far stricter engineering than quarterly releases ever did” AI generation Hand-written code “Generation can be flexible. … But evaluation must be rigid.” “When something looks like recklessness, look for where the discipline moved.” 8
9. Compile to architecture “Software should not compile directly to frameworks. It should compile to architecture.” spec regenerable components architecture implementations The analogy A compiler source code ISA (instruction set architecture), e.g. x86-64 Intel · AMD · the next chip Now spec architecture React · .NET · the next framework stays changes 9
10. Compile to architecture What must survive deletion? Primitive What it is Why it must survive Specification What the system must do (intent) The new code is generated from it Evaluation How we know it works (tests, checks) Proves the regenerated code is correct Context boundary Where one part ends and another begins: contracts, event schemas Defines what can be deleted and regenerated on its own Provenance Why a decision was made The reasons don’t disappear with the code But “The implementation remembers. The organization forgets.” What it remembers is a shadow spec. “Specification, evaluation, context boundary, and provenance are the minimum set” · The Phoenix Primitives 10
11. The limit of Phoenix Regeneration is a diagnostic, not a destination. Regenerate, diff the behavior, and every difference is knowledge you never wrote down. Diff findings emails are lowercased retry twice on timeout VAT rounds half up Each one is a shadow spec. 11
12. $ rm -rf src/ 12
13. What survives deletion? Specification Evaluation Context boundary Provenance Where one part ends and another begins $ rm -rf src/ Who decides where that line goes? 13
14. What survives deletion? Specification Context boundary Evaluation Team A Provenance Team B UI LoanController HoldController InvoiceController PaymentController Service LoanService MemberService BillingService FineService Data Member Loan Account Invoice Who decides where that line goes? 1 ·2technical · team chart? layers? 14
15. What survives deletion? Specification Evaluation Lending Context boundary Provenance Billing LoanController HoldController InvoiceController PaymentController LoanService MemberService BillingService FineService Member Loan Invoice Account · payer Account · member Who decides where that line goes? 3 · meaning ✓ 15
16. Welcome to yet another boring DDD talk. :) Still here after 20+ years. 16
17. We’ve had a name for this for 20+ years Bounded Context “A description of a boundary … within which a particular model is defined and applicable.” Eric Evans, Domain-Driven Design Reference (2015) Context boundary (Chad Fowler, 2026) ≈ Bounded context (Eric Evans, 2003) 17
18. Part 2 · SDD in one minute What a spec is Intent Goals Non-goals Why this, why now, and for whom What becomes true What stays false, deliberately Constraints Acceptance criteria Open questions What must hold regardless of approach How we will know. Each one able to fail. What we don’t know yet, and who decides Notice what is absent: how. 18
19. How I actually use it Framework choice and what I learned Same loop, two scales. Each step’s output is the next step’s input. BMAD · project altitude · once 1 · in: idea, research 2 · in: brief.md 3 · in: prd.md 4 · in: prd + architecture product-brief prd architecture epics-and-stories out: brief.md out: prd.md out: architecture.md out: epics.md, stories Handoff one story from epics.md becomes the input of the feature loop Superpowers · feature altitude · every story 1 · in: story 2 3 4 5 6 7 brainstorming worktree writing plans subagent tasks TDD code review finish branch out: design spec out: isolated branch out: plan.md out: a commit per task out: tests + code out: review against spec out: PR, merge alperhankendi.github.io/claude-code-mastery/15-Agentic-Coding-Frameworks 19
20. What it looks like on disk repo/ ├── CLAUDE.md the map ├── docs/ │ ├── product/ project altitude │ │ ├── 00-brief.md │ │ ├── 10-prd.md │ │ └── 20-architecture.md │ ├── specs/ feature altitude │ │ ├── S-014-hold-queue.md │ │ └── S-015-overdue-policy.md │ └── plans/ one change each │ └── S-014-plan.md ├── src/ └── tests/ durable product/ specs/ tests/ disposable plans/ src/ Where does the domain live? 20
21. The tempting map docs/specs/ → problem space (what, why) docs/plans/ → solution space (how) It’s too clean. 21
22. The missing layer The domain has no home of its own. In typical SDD templates, entities and terms exist, but nothing is organized around the domain. chatsync · 5 specs → license · 4 specs → 22
23. Scattered per feature, or buried in a product doc Tool What persists Where the domain ends up GitHub Spec Kit constitution.md: principles, governance Key Entities, data-model.md: per feature folder AWS Kiro Steering: product, tech, structure Per-feature specs; no glossary by default BMAD (closest) PRD with a real Glossary Inside the PRD, per initiative; no bounded contexts “Related decisions can be spread across multiple feature directories” GitHub Spec Kit docs, Spec persistence 23
24. “in order to make ubiquitous language work at scale, you need bounded contexts” Martin Fowler, DDD Europe 2026 The bounded context is the unit of regeneration. 25
25. Chad Fowler saw it too “The Specification Is Not a Document” (Aug 2026) Payments One retry rule for a failed payment authorization Reliability Compliance One rule, three homes. A document makes you pick one. 24
26. Same diagnosis, two answers Chad Fowler This talk “Perhaps we should store the graph instead.” Organize knowledge by bounded context. In practice, from my SDD workshop: specs as a graph A graph tells you how things connect. A bounded context tells you where a word means one thing. # key-rotation.spec.md Relates to: revocation.spec.md Inherits: platform-constraints.spec.md Supersedes: key-rotation.v1.spec.md 25
27. Specs mutate too Feature-by-feature specs repeat mutation at the spec level. specs/003-checkout/ Customer = the buyer specs/014-invoicing/ Customer = the billing account specs/027-support/ Customer = whoever opened the ticket $ rm -rf specs/ Run the Deletion Test on your specs. If you are afraid to delete your old specs, your specs are the new legacy. 26
28. Four layers, four speeds Layer DDD SDD artifact Lifetime Durable knowledge Domain, subdomains, ubiquitous language glossary, domain.md, context map (usually missing) Slow Problem space The feature’s problem within the domain spec.md, PRD Life of the feature Solution space Bounded context, model, aggregate plan.md, ADR Medium Implementation Code tasks.md, code Disposable Today the slowest layer has no file. 27
29. The bottleneck just moved code generation: faster than ever developers ↔ domain “…just moving the bottleneck” “domain-driven design is all about working on that bottleneck” Martin Fowler, with Eric Evans, DDD Europe 2026 28
30. Strategic matters more Matters more · strategic Matters less · some tactical patterns Ubiquitous language Bounded contexts Context map Subdomains Repository Factory Value Objects Domain Services Patterns regenerate. Boundaries must be decided. 29
31. The aggregate survives Order Repository Invariant: an order can’t be confirmed without a line. consistency boundary Factory Invariants live in specs and evaluations, not only in code. 30
32. Part 3 · Where to start in brownfield Your legacy system fails the Deletion Test. That’s not the verdict. That’s the map. Fear is a signal: it shows where knowledge lives only in code. 31
33. Knowledge first, specs second    Structural Linguistic Behavioral What depends on what What the words mean What it actually does today dependency graph, git history glossary, event storming characterization tests, telemetry A spec written before these three is a guess about the system. 32
34. Tools recover structure. Humans recover meaning. Humans: what words mean, which rules are invariants, which bugs are features. Example (structural): Ctxo, open-source MCP server · github.com/alperhankendi/ctxo 33
35. Draw the as-is context map Billing? InvoiceService.cs TaxCalc.cs DunningJob.cs Pricing? shared table PriceRules.cs Discounts.cs QuoteBuilder.cs Files that change together are one concept, or coupled by accident. Clusters are candidates. Naming them is human work. Co-change from git history (e.g. Ctxo, or plain git log) 34
36. Draw the boundary: an anti-corruption layer Legacy ACL New context status = 3 translates InvoiceOverdue The ACL is where legacy meaning gets written down for the first time. Anti-corruption layer: Eric Evans, Domain-Driven Design (2003) 35
37. SDD inside. Strangler outside. Inside the new context Outside Computational sensors spec → plan → code routes move from legacy to new, one at a time characterization tests contract tests at the ACL architecture tests Ctxo blast radius & PR impact regenerate freely “push towards computational sensors, not inferential” Harness engineering for coding agent users by Birgitta Böckeler Strangler fig pattern by Martin Fowler 36
38. Model the core domain. Buy the generic. Core Supporting Generic Model it: language, aggregates, specs, evals Keep it simple Buy it. Don’t spec it. Spend your scarce human attention where your domain is different. 37
39. From fear of deletion to boredom of deletion Boring Bounded Named Pinned Fear ACL, strangler spec and evals per context glossary, context map characterization tests knowledge only in code “The goal is to build systems where deletion is boring.” The Deletion Test 38
40. Closing From Code Ownership to System Stewardship The steward works the bottleneck: the domain. 37
41. $ rm -rf src/ remaining: language · boundaries · specs · evaluations · decisions What survives deletion is your domain knowledge. Code is disposable. Make the domain durable. 39
42. Takeaways Disposable Code is a cache. Keep the knowledge out of it: specs, evaluations, decisions. Durable Give the domain a home. A ubiquitous language and a context map that outlive every feature spec. Day one Start with the Deletion Test. Find where knowledge lives only in code. Write it down, one bounded context at a time. 40
43. Thank you Ctxo Agentic Coding Frameworks github.com/alperhankendi/ctxo alperhankendi.github.io/claude-code-mastery