Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Building Rich Domain Models with DDD and TDD - ...

Building Rich Domain Models with DDD and TDD - Betsson DevTalk

Ivan Paulovich

September 12, 2018
Tweet

More Decks by Ivan Paulovich

Other Decks in Programming

Transcript

  1. Building Rich 
 Domain Models 
 with DDD and TDD

    [email protected] https://paulovich.net Ivan Paulovich Betsson Dev'talk #3 Stockholm – September 12th, 2018 @ivanpaulovich
  2. Betsson Wallet Team • Seniors Developers • Agile Team •

    Business Oriented • .NET – SQL Server – Angular • Stockholm Office • We are hiring!
  3. 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
  4. DDD TDD Tiny Domain Objects Exploratoring Code Focus on Unit

    Tests Frequent Short Cycles Quick Feedback Self Explanatory Coding Frequent Rewriting Freedom to Change
  5. 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.
  6. • Not a technology. • Not a methodology. • Set

    of principles and patterns for focusing the design effort where it matters most.
  7. 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.
  8. DDD express the Model with 
 Value Objects, Entities and

    Services. Some Entities act as root of Aggregates.
  9. 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.
  10. 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
  11. 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.
  12. Customer Account Credit First Name Last Name Opening Date Personnummer

    Debit Amount Transaction
 Date Description Tactical-Design Mobile Phone 
 Number Amount Transaction
 Date Description
  13. Customer Account Credit First Name Last Name Opening Date Personnummer

    Debit Amount Transaction
 Date Description Tactical-Design Mobile Phone 
 Number Amount Transaction
 Date Description
  14. 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
  15. 
 
 
 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
  16. Entities • Have a unique identity. • Are mutable or

    not. • Refer others entities by their IDs. • Don't get trapped by datastore thinking.
  17. 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.
  18. Account Aggregate Root It is an Entity Only mandatory fields

    are 
 required in the constructor Implements behaviors which maintain the state consistent.
  19. 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.
  20. 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
  21. 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
  22. 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
  23. .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
  24. 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
  25. First-Class TransactionCollection Copy collections and mutable objects when passing them

    between objects.¹ ¹Growing Object-Oriented Software Guided by Tests, 2010
  26. How to Use the TransactionCollection Class The GetBalance() implementation belongs

    to the TransactionCollection class. Composite simpler than 
 the sum of its parts
  27. Write a failing
 acceptance test Write a 
 failing
 unit

    test Make the test pass Refactor Inner and outer feedback loops in TDD
  28. 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!
  29. Entities Use Cases Controllers Presenters Gateways Devices W eb UI

    External Interfaces DB Isolate the Domain with a Layered Architecture Outside In Inside Out
  30. 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
  31. Implementation Samples • Clean Architecture • Hexagonal Architecture • Event

    Sourcing • DDD • TDD • Microservices Fork m e on G itH ub
  32. 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