Discovering the value of Domain-Driven Design

1. Discovering the value of Domain-Driven Design • presented by Herman Lintvelt • (c) 2011 Polymorph Systems

2. Do the right thing, and do the thing right. “When we first set out to write software, we never know enough.”

3. ? What are some of the prominent problems you struggle with in your software development projects?

4. ? When faced with these problems or complex requirements, how do you go about to resolve them?

5. An Experiment In which we make use of volunteers to do some role-playing.

6. Scenario A

7. Scenario A

8. Scenario B

9. Scenario B

10. Scenario B

11. So what was the difference? • Build up a model of the domain to enhance understanding • Based on this a common language was being developed • New understanding immediately fed into model and language

12. Coming to terms... • Domain: • subject area to which solution must be applied • Domain Model: • simplification of real world • abstracts aspects relevant to solving problem at hand • not just a particular diagram • Ubiquitous Language: • everywhere the same language

13. What is DDD? • DDD is both way of thinking and set of priorities • aimed to accelerate software dealing with complex domains • primary focus on domain and domain logic • complex domain designs should be based on a model • Two development practices prerequisites: • Development is iterative • Developers and domain experts have a close relationship

14. Model Code Language Where does DDD fit? • DDD is not a new idea! • Central part of OO Analysis & Design

15. ? What are different nouns that can be used for “car”?

16. car • vehicle • bakkie • automobile • SUV • minibus • HMUV (High Mobility Utility Vehicle) • jamjar (Cockney slang)

17. Case Study 0 • 5.1.7 [Req-XXXX] - Car Finder • Allow the end user to locate itself and the vehicle.

18. Case Study 0 • - (SoapRequest*) GetLastKnownVehiclePosition: • (id <SoapDelegate>) handler • uiTokenID: (NSString*) uiTokenID • vehicleRegistrationNr: (NSString*) vehicleRegistrationNr; • - (SoapRequest*) UnitPlayback: • (id <SoapDelegate>) handler • uiTokenID: (NSString*) uiTokenID • dtStartDate: (NSDate*) dtStartDate • dtEndDate: (NSDate*) dtEndDate • liCustomerVehicleID: (long) liCustomerVehicleID;

19. Case Study 0

20. Case Study 1 • As a user of the XXXX iphone application • I want to view my current location and my car’s location on a map, with the shortest route indicated visually • So that I can easily find my car

21. Case Study 1

22. Case Study 1

23. Case Study 1 • The direct benefits we gained in project: • Simpler code • better separation in layers • Faster development • requirements, code & tests could be verified against domain model • easier to debug & refactor in domain layer than in UI, Persistence, Web-service layers • Focused on correct user stories • Better tested • Team interaction & communication improved dramatically

24. Utility of a Model • In DDD, the Model has 3 basic uses: • The model and the heart of the design shape each other • makes model relevant, ensures the analysis applies to final product • The model is a backbone of a language used by all team members • The model is distilled knowledge • team’s agreed way of structuring domain knowledge and key domain elements

25. Model Code Language DDD and DSLs • DSL “allows solutions to be expressed more clearly and closer to the domain” • Model can be expressed as DSL • DSL can be used to • generate scaffolding code • generate specification and test docs • define business (domain) rules

26. Ingredients of Effective Modeling • Binding the model and the implementation • Cultivating a language based on the model • can also include technical terms to be taught to domain experts • Developing a knowledge-rich model • Objects not just data scheme (anemic objects), but has behaviour and enforce rules • Distilling the model • Brainstorming and experimenting • Agile modeling, Model out Loud

27. Deep Domain Model • When faced with complexity, do you • deepen your domain knowledge • OR deepen your technology stack?

28. Sad Example • Client: “Our system is very expensive to maintain, and performance is horrible” • Me: “Why do you think?” • Client: “Well, cause we’re using Java and it is really slow and has a high learning curve” • Me: “Interesting. Tell me about the business domain of the system...” • Client: “Well, we’re integrating with a legacy system and use Java EE and added ESB to help with that....”

29. Modeling out Loud • People has a genius for spoken language • Unfortunately they usually don’t use the language of domain model when speaking • We must harness linguistic ability to the modeling effort • It complements the visual/spatial reasoning done by sketching diagrams • As we model out loud, we find easier ways to say what we need to say • NB to then take those new ideas back to the diagrams and code

30. ? Discuss what you see as benefits of DDD that applies to your current projects of software development circumstances? What benefits will you gain if you start thinking and designing more domain-focused? (short, medium, long term?)

31. DDD Benefits • Allows effective collaboration • Earlier experience feed back into model and understanding of whole team • Helps focus requirement analysis • Allows evolving of model over time • “When we first set out to write software, we never know enough.”

32. References • Applying UML and Patterns, Prentice Hall - Craig Larman • Domain Driven Design, Addison-Wesley - Eric Evans

33. If you want... • contact me: • herman@polymorph.co.za • http://www.polymorph.co.za • twitter: hermanlintvelt • blog: http://blog.richclientgui.com • training: http://jtraining.co.za • OO A&D Course, CapeTown, end of July • Thank you