From ddd to DDD : My journey from data-driven development to Domain-Driven Design
0 likes549 views
The document details the evolution of software design and architecture in an e-commerce context, highlighting challenges faced with legacy systems, testing, and collaboration issues in a large organization. It emphasizes the transition from database-driven to code-centric logic, advocating for Domain-Driven Design (DDD) principles, command-query separation (CQS), and command-query responsibility segregation (CQRS). Key takeaways include the importance of introducing DDD concepts gradually, continuous improvement, and the need to tailor tools to specific business contexts.
From ddd to DDD : My journey from data-driven development to Domain-Driven Design
- 1. From ddd to DDD An ongoing journey Thibaud Desodt - @tsimbalar
- 2. What this is about • Me, myself and I • Code • Architecture • Learning process
- 3. Where it all started
- 4. E-commerce site ASP.NET / C# Back-office site “classic” ASP / VbScript Data Tables Stored Procedures T-SQL PRESENTATION BUSINESS LOGIC DATA
- 5. And it was … • Not super pleasant • VbScript • T-SQL • Fragile • No automated tests • Tight coupling • Schema -> Stored Procs -> Website / admin site
- 6. … but it worked “well enough”! • Customer value • Happy customer • Fast delivery of features • Reasonable perf • Easy to work on • 1 feature ≈ 1 stored procedure
- 7. It worked well ... in that context • Working alone on project • Version 1 of the product • Well-defined requirements • Tight interactions with customer • Simple domain = ideal greenfield project
- 8. A few years later … Similar approach, different context
- 9. A different context • 40,000+ employees company • 100s of developers spread across the globe • Many different systems accessing the database(s)
- 10. This scripts that runs every night That excel sheet nobody understands Admin CRUD app Quotation app Data 800+ Tables 3000+ Stored Procedures T-SQL Customer-facing web appsB2B SOAP services Internal Catalogue app Reporting App Bob running random SQL queries The Enterprise Database ™
- 12. Many issues • Evolution is hard • Testing is hard • Versioning / collaboration is hard • Performance is not great
- 13. the “solution” …. • Team of 50 DBAs • The “database” committee • The “database” change process • The “meta-database” • Db replication • Governance Technical solutions … to solve technical issues … introduced because of technical decisions … with no value to the users = Accidental complexity
- 15. Moving away from database-driven • Persistence is an implementation detail • Focus on customer value Relational DB, Document DB, Key-Value store, file … Who cares ? Business > Tech
- 16. App PRESENTATION DATA BUSINESS LOGIC PRESENTATION DATA BUSINESS LOGIC Bringing the logic back to the code
- 17. Bringing the logic back to the code • No more Stored Procedures • ORM (Entity Framework in that case) • Data-access code + Entities* generated from database * Not quite
- 20. Status That’s better ! • No more business logic in the DB • Quite readable Still a bit messy: • Not testable • Hard coupling DATA BUSINESS LOGIC
- 21. Better layering
- 22. DATA BUSINESS LOGIC Better layering Services Repositories + Unit of Work Abstract away details of how data is accessed Orchestrate data-flow for a given use-case
- 23. Repository
- 24. A “Service”
- 25. Status Quite an improvement • Decoupled • Testable • Easy to know where functionality should live • It worked fine initially But … wait a minute …
- 26. Object graphs When loading an Order from DB …what else should I load ? - All the relationships ? - Some of them, and leave some unpopulated (null) ? - Some of them, and use lazy- loading ? define Aggregates Deliberately delimit clusters of objects that live together and are loaded/stored together. … keep them as small as possible
- 27. Object graphs identify the Aggregate Root The unique entry point to the graph Dependencies go only in one direction Repositories return Aggregates through their root
- 28. More smells … Transaction Script Anemic Domain Model
- 29. Fighting the Anemic Domain Model • Do not expose setters • Do expose only the Aggregate Root • Do enforce invariants (guard clauses) • Do mutations only through methods • Use intent-revealing names (no Update(…) methods) Make invalid states impossible to represent
- 30. Transaction Script -> Application Service 1. Load aggregate root from repository 2. Mutate by invoking methods 3. Save to DB
- 31. Methods on Domain Entities Intent-revealing name Make forbidden state impossible Avoid primitive types
- 32. Status Even better • Decoupled • Testable • Easy to know where functionality should live • Explicit models and methods • Clean encapsulation • Meaningful names PRESENTATION DATA Application Services Repositories Aggregates
- 33. What about views ? We defined • Small aggregates • Repositories targeting only Aggregate Roots • Transactional consistency • Repositories hiding data-access For views / reports we need • JOINs across many tables • Small ad-hoc queries on some tables • No transactions • Access to raw data / perf Different needs require different tools
- 34. Separating Reads and Writes • Commands vs Queries • Write Model vs Read Model CQS (Command Query Separation) CQRS (Command Query Responsibility Segregation) Aggregates View-specific projections As big or small as needed
- 35. WRITE READ Commands Application Service Repository Commands Commands 1. Load aggregate from repository 2. Validate / mutate 3. Save changes Direct access to the data Queries QueriesQueries Query Handler * * Maybe same as primary, maybe totally different
- 36. Expose only Aggregates Write Model Read Model Allow edits Read-only Expose projections, DTOs tailored for the view
- 37. Status Good enough for now ☺ • Decoupled • Testable • Easy to know where functionality should live • Explicit models and methods • Clean encapsulation • Meaningful names • Correct writes • Fast Reads
- 38. Take aways • Smoothly introduce DDD concepts • Failing is learning • Watch out for smells • Continuously improve • The right tool for the right job • Context is king
- 39. Going further Some important concepts I left out : • Value Objects • Bounded Contexts • Ubiquitous Language • Domain Events • Context Mapping • …
- 40. Thanks for listening ! Questions ? Thibaud Desodt - @tsimbalar