Domain Driven Design in an Agile World


Published on

Agile practitioners can be design avoidant! DDD helps improve communication through ubiquitous language; improve thinking through mapping patterns; and ensuring design and reality match.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Domain Driven Design in an Agile World

  1. 1. DOMAIN DRIVENDESIGNPrepared for the 4th Software Engineering ColloquiumLorraine Steyn and Paul Johnson
  2. 2. Domain Driven Design 2Home TruthsA design should be as simple as possible, but no simplerAgile development is about collaboration and communication
  3. 3. Domain Driven Design 3Agile, brieflyAgile practitioners can be design avoidant!  Avoid documentation, no big upfront analysisScrum and Agile encourage rapid change  Quicker route to the BOM  No time for design?  Small user stories lose the big picture  Scrum is particularly Process focused, and does not prescribe the technical approach
  4. 4. Domain Driven Design 4Agile – the good bitsShort iterations  Deliver working software in 2 to 3 week “sprints”Empower people  Team ownership  Team commitment to deliverStructured Process through Scrum  The ability to respond to change is Agile, through a highly structured approach  New ways of working: Pair programming, test-driven development
  5. 5. Domain Driven Design 5How does DDD Help? Communication improved by ubiquitous language  Between team and client  All the way through to the code Design thinking improved by applying standard patterns  Leverage off the wisdom of others  Double edged sword if a pattern is mis-identified Ensure design and reality match  Model stories and scenarios using concrete examples  Refactor, refactor…
  6. 6. Domain Driven Design 6Ubiquitous Language Evolve the language, don’t define it upfront  Client, customer, user, stakeholder, person, accountholder, payer ???  Bounded context Bridge the IT/Domain expert divide  Remove technical aspects (server, logger etc)  No technical jargon (stored proc, XML etc)  Clarify business terms and insist on consistent usage  Make it natural
  7. 7. Domain Driven Design 7In practice…Domain Expert DeveloperThe correct risk factor must be We can do that quite easily if weused when we calculate the create another adjustment typeinsurance premium. and modify the stored proc.What is this stored proc you talk Never mind, it’s kind of like aabout? spreadsheet macro.So how will this work as an Well, we already have adjustmentadjustment? types for loyalty and zero-claim discounts, so we can add risk factor as another type.But loyalty and zero-claim are Well, all those things are handledbenefits, not discounts! as adjustments in the system. Trust me!
  8. 8. Domain Driven Design 8Ubiquitous Language Rules Let the model do the talking  Look at the model (sketch) and tell a story  Look at the code and tell the same story Define structured stories  As a … I want … So that …  Identify user value (start by understanding their world) Define specific scenarios that model behaviour we can test  Given (/and)… When … Then …
  9. 9. Domain Driven Design 9Doing it rightBusiness Story As a new customer I want to know how much extra my insurance will cost if I use my private car for business purposes So that I can check if I am still within budgetScenario 1 Given the market value of my car is R100,000 And the car is used for private purposes only And the risk factor is 0.15% for cars valued R100,000 When the premium is calculated Then the premium should be R150
  10. 10. Domain Driven Design 10The Neglected VerbNouns are easyKRS client in the Shipping industry definedactions (verbs) for a crew transfer form:Complete - Filled inAcceptedConfirmed - Planner processes transferAuthorizedAccepted - Manager approves transferConfirmedAuthorized - Ship is notified of transfer
  11. 11. Domain Driven Design 11Considering a ModelDesign emerges…  Communication tool  Patterns appear as you build the modelIEEE: Software Engineering is the application of asystematic, disciplined, quantifiable approach todevelopment…Tools don’t matter: UML, BPM, any sketch can be a modelYAGNI / KISS
  12. 12. Domain Driven Design 12The Core ModelLayered approach:  Presentation / User Interface  Application Layer (stateless, eg. Menu items)  Domain / Business Logic  Infrastructure / Persistence (DB)Identify contextsIdentify interfacesLook for behaviourLook for value
  13. 13. Domain Driven Design 13Entities and Value ObjectsEntities  Nouns  Identity  eg. Person, Sale, Stock, VehicleValue Objects  We care about what an object has, not what it is  Immutable  Lightweight  eg. Calendar, Price, Age, Vehicle Type
  14. 14. Domain Driven Design 14In practice…Create a quote for a hotel booking:  Check in date, check out date  Number of rooms
  15. 15. Domain Driven Design 15 EntityValue Object
  16. 16. Domain Driven Design 16Mapping PatternsShared KernelCustomer / SupplierConformistSeparate WaysAnti-corruption Layer Aggregates Factories Repositories
  17. 17. Domain Driven Design 17Aggregates
  18. 18. Domain Driven Design 18Exploring the DomainDomains are often complexMost domains have subtletiesYou need to dig deepYour design should improve as you go  You have to refactor as you goWhat happens if you implement the designthat you first thought of?  You lock in your ignorance – Eric Evans
  19. 19. Domain Driven Design 19In practice…Scenario 1 Given the market value of my car is R100,000 And the car is used for private purposes only And the risk factor is 0.15% for cars valued R100,000 When the premium is calculated Then the premium should be R150
  20. 20. Domain Driven Design 20In practice…@Testclass CalcuatePremiumForCars { private CarPremiumCalculator calculator = new CarPremiumCalculator; public void carUsedForPrivateUseOnly() { // Given the market value of my car is R100,000 Money marketValue = new Money(100000); // and the car is used for private purposes only boolean isForPrivateUse = true; // and the risk factor is currently 0.15% for cars valued R100,000 calculator.addRiskFactor(1000000, 0.15); // When the premium is calculated Money premium = calculator.calculate(marketValue,isForPrivateUse); // Then the premium should be R150 assertEquals(new Money(150), premium); }
  21. 21. Domain Driven Design 21Lessons from KRSDDD isn’t just for architectsWe teach DDD to our internsIt results in better software  Forces developers to think in layers  Concrete scenarios get developers closer to the true business requirements quicker  Scenarios become your tests  Ubiquitous language breaks down barriers between users and developers  Better software becomes a habit
  22. 22. Domain Driven Design 22 Questions? (021) 681 2900Lorraine Steyn: Johnson: