Building Rich Domain Models with DDD and TDD - Betsson DevTalk

Transcript

1. Building Rich 
 Domain Models 
 with DDD and TDD ivan@paulovich.net https://paulovich.net Ivan Paulovich Betsson Dev'talk #3 Stockholm – September 12th, 2018 @ivanpaulovich
2. Ivan Paulovich Photo by Rafaela Biazi on Unsplash 30+ Microsoft Certifications paulovich.net Developer
3. Betsson Wallet Team • Seniors Developers • Agile Team • Business Oriented • .NET – SQL Server – Angular • Stockholm Office • We are hiring!
4. How to shoot yourself in the foot: 1. Design your application starting from the data model. 2. Create your domain model by reverse engineering. 3. Pretend that you’re doing TDD and start testing your domain classes. • Particularly getters and setters. 4. Now start testing the logic with Integration Tests and get stuck by test data and related issues. 5. Declare that TDD provides no benefit and only slows you down. 6. Comment tests in your Continuous Integration proccess. 7. Keep on whining. Alberto Brandolini
5. DDD TDD Tiny Domain Objects Exploratoring Code Focus on Unit Tests Frequent Short Cycles Quick Feedback Self Explanatory Coding Frequent Rewriting Freedom to Change
6. A Customer Entity with Primitive Obsession...
7. Leads to Services Like.. • Needs to verify for required parameters • Needs to verify for Data Format • Needs to verify for Data Range • Services are Big and Fat • Easy to confuse one parameter with the another.
8. • Not a technology. • Not a methodology. • Set of principles and patterns for focusing the design effort where it matters most.
9. An Customer Entity Using Value Objects..
10. Business Rules Enforced Through Value Objects • The simple existence of a Value Object means that it is valid. • No need to verify for the data format on every method. • Services are thinner when using Value Objets.
11. DDD express the Model with 
 Value Objects, Entities and Services. Some Entities act as root of Aggregates.
12. An Example with Some Use Cases • A customer can register a new account using its personal details. • Allow a customer to deposit funds into an existing account. • Allow to withdraw from an existing account. • Do not allow to withdraw more than the existing funds.
13. Account Number 4444-6 Date Description Debit (SEK) Credit (SEK) Balance (SEK) 08-01-2018 Initial Balance 50,000 08-03-2018 Withdrawal 10,000 40,000 08-06-2018 Withdrawal 5,000 35,000 08-17-2018 Deposited 7,000 42,000 Account Number 7777-0 Date Description Debit (SEK) Credit (SEK) Balance (SEK) 08-01-2018 Initial Balance 10,000 Customer 5557-8
14. Some Names and Verbs are Useful • A customer can register a new account using its personal details. • Allow a customer to deposit funds into an existing account. • Allow to withdraw from an existing account. • Do not allow to withdraw more than the existing funds.
15. Customer Account Credit First Name Last Name Opening Date Personnummer Debit Amount Transaction
 Date Description Tactical-Design Mobile Phone 
 Number Amount Transaction
 Date Description
16. Customer Account Credit First Name Last Name Opening Date Personnummer Debit Amount Transaction
 Date Description Tactical-Design Mobile Phone 
 Number Amount Transaction
 Date Description
17. Customer Account Credit First Name Last Name Opening Date Personnummer Debit Amount Transaction
 Date Description Tactical-Design Mobile Phone 
 Number Personal Expenses 
 Bounded Context Amount Transaction
 Date Description
18. 
 
 
 Domain Model 
 Terms
 Names of 
 Bounded Contexts 
 Terminology of Large-scale 
 Structures
 DDD Patterns 
 Names Business Terms 
 Developers Don’t 
 Understand
 Business Terms 
 Everyone Uses
 That Don’t Apper 
 in Design 
 Technical Aspects 
 of Design
 
 Technical 
 Terms 
 Technical Design
 Patterns Developers Domain Experts Ubiquitous
 Language
19. Entities • Have a unique identity. • Are mutable or not. • Refer others entities by their IDs. • Don't get trapped by datastore thinking.
20. Aggregate Roots (Are Entities) • Refer other aggregates by identity only. • Scope of consistency inside the aggregate boundaries and update other aggregates through eventual consistency. • Aggregates are small. • Aggregates implement behaviors. • One Aggregate Root for every Entity is a Code Smell.
21. An Aggregate Root is not your Entire Model
22. An Aggregate Root
23. Account Aggregate Root
24. Account Aggregate Root It is an Entity
25. Account Aggregate Root It is an Entity Only mandatory fields are 
 required in the constructor
26. Account Aggregate Root It is an Entity Only mandatory fields are 
 required in the constructor Implements behaviors which maintain the state consistent.
27. Account Aggregate Root It is an Entity Factory method to restore state. Only mandatory fields are 
 required in the constructor Implements behaviors which maintain the state consistent.
28. Value Objects • Immutable. • Have no explicit identity. • Unique by the comparisson of the atributes. • Used to describe, measure or quantify an Entity. First Name Last Name Personnummer Mobile Phone 
 Number Amount Description
29. Personal Expenses
 Bounded Context .NET
 Bounded Context Mobile Phone 
 Number string
30. Personal Expenses
 Bounded Context .NET
 Bounded Context Mobile Phone 
 Number string Clone Compare CompareOrdinal CompareTo Concat Contains Copy CopyTo Create EndsWith Equals Format GetEnumerator GetHashCode GetTypeCode IndexOf IndexOfAny Insert Intern IsInterned IsNormalized IsNullOrEmpty IsNullOrWhiteSpac e Join LastIndexOf LastIndexOfAny Normalize PadLeft PadRight Remove Replace Split StartsWith Substring ToCharArray ToLower ToLowerInvariant ToString ToUpper ToUpperInvariant Trim TrimEnd TrimStart
31. Personal Expenses
 Bounded Context .NET
 Bounded Context Mobile Phone 
 Number Create GetAreaCode GetLastFourDigits ToString string Clone Compare CompareOrdinal CompareTo Concat Contains Copy CopyTo Create EndsWith Equals Format GetEnumerator GetHashCode GetTypeCode IndexOf IndexOfAny Insert Intern IsInterned IsNormalized IsNullOrEmpty IsNullOrWhiteSpac e Join LastIndexOf LastIndexOfAny Normalize PadLeft PadRight Remove Replace Split StartsWith Substring ToCharArray ToLower ToLowerInvariant ToString ToUpper ToUpperInvariant Trim TrimEnd TrimStart
32. .NET
 Bounded Context 
 Thread Personal Expenses
 Bounded Context .NET
 Bounded Context Personal Expenses
 Bounded Context We only pay for the complexity 
 we really use string Phone Number 
 Thread null string int Reflection double collection HttpClient Without Value Objects With Value Objects We bring the .NET Framework Complexity 
 into our Bounded Context. null int Reflection double collection HttpClient
33. Personnummer Value Object
34. First-Class Collections • Each collection should be wrapped in its own class¹. • Classes that contains collections do not contains any other variable. • Behaviors have a home. • When necessary return immutable collection copies. Account Transaction 1:N ¹The ThoughtWorks Anthology: Essays on Software Technology and Innovation (Pragmatic Programmers), 2008
35. First-Class TransactionCollection
36. First-Class TransactionCollection Copy collections and mutable objects when passing them between objects.¹ ¹Growing Object-Oriented Software Guided by Tests, 2010
37. How to Use the TransactionCollection Class
38. How to Use the TransactionCollection Class The GetBalance() implementation belongs to the TransactionCollection class.
39. How to Use the TransactionCollection Class The GetBalance() implementation belongs to the TransactionCollection class. Composite simpler than 
 the sum of its parts
40. Write a failing
 acceptance test Write a 
 failing
 unit test Make the test pass Refactor Inner and outer feedback loops in TDD
48. Opinionated DDD/TDD • Sometimes I implement too much of the Domain Model. Then return to covering it with unit tests. • By knowing the DDD patterns I understimate the TDD value then 
 I'm slapped in the face. • My goal is to maintain a high test coverage on the Domain Model. • If testing is hard. It is an architectural issue!
49. I won’t reverse engineer my data model to create a
 domain model.
50. The Stable Dependencies Principle¹ ¹Clean Architecture, Robert C. Martin, 2017
51. The Stable Dependencies Principle Infrastructure Web Domain Application
52. The Stable Dependencies Principle Infrastructure Web Domain Application Shinning Framework Shinning Library
53. The Stable Dependencies Principle Infrastructure Web Domain Application Shinning Framework Shinning Library
54. Entities Use Cases Controllers Presenters Gateways Devices W eb UI External Interfaces DB Isolate the Domain with a Layered Architecture Outside In Inside Out
55. Entities Use Cases Controllers Presenters Gateways Devices W eb UI External Interfaces DB • Testability • Hexagonability • Use Cases as First-Class • Decoupled Isolate the Domain with a Layered Architecture
56. DDD Patterns Ubiquitous Language Testing Application Design Implementation Samples Quick Review
57. DDD Patterns Ubiquitous Language Testing Application Design Implementation Samples Quick Review
58. Implementation Samples • Clean Architecture • Hexagonal Architecture • Event Sourcing • DDD • TDD • Microservices Fork m e on G itH ub
59. Resources • Domain-driven Design, Eric J. Evans, 2003 • The ThoughtWorks Anthology: Essays on Software Technology and Innovation (Pragmatic Programmers), 2008 • Clean Architecture, Robert C. Martin, 2017 • Growing Object-Oriented Software, Guided by Tests, 1st Edition, 2009