Up to speed in domain driven design

2,327 views

Published on

A presentation I held about a year ago at the Dutch DDD user group

Published in: Technology

Up to speed in domain driven design

  1. 1. Up to Speed in Domain Driven Design Rick van der Arend rvdarend@sogyo.nl
  2. 2. Agenda  What is Domain Driven Design?  An example of a domain model  The building blocks of a domain model  Refactoring towards deeper insight  What has been learned since the book?  Wrap-up SOFTWARE INNOVATORS 2
  3. 3. SOFTWARE INNOVATORS 3 What is DDD? “Putting the Domain Model to work”
  4. 4. DDD in one sentence  Domain Driven Design is a style of software development which focuses on removing translation barriers between domain, development team and design of working software using a ubiquitous language supported by a well refined livingmodel.
  5. 5. Translation barriers  Team talks to users and experts (if lucky)  Write software that behaves as requested  Names get translated back and forth  Concepts diverge without anyone noticing SOFTWARE INNOVATORS 5 ?
  6. 6. Domain, Team and Model Ubiquitous Language
  7. 7. Origins of the acronym DDD  Eric Evans wrote the book that gave the acronym DDD an impulse in 2005. Aptly named: Domain Driven Design “Tackling Complexity in the heart of software”
  8. 8. SOFTWARE INNOVATORS 8 An Example of a domain model
  9. 9. Domain model SOFTWARE INNOVATORS 9 Parallel to the equator Parallel to the earth axis Orthogonal to the sun’s plain of movement Turning during the year
  10. 10. From Phased to Iterations Analysis Design Build Iteration Iteration Test
  11. 11. Start with the Model, don’t stop SOFTWARE INNOVATORS 11 Iteration Iteration Domain Model effort as part of an iteration
  12. 12. SOFTWARE INNOVATORS 12 The building blocks of a Model-Driven Design
  13. 13. Building blocks of MDD
  14. 14. Entities & Value objects  Entities have an unmistakeable identity  Value objects are indentified by.. their value  a Person  a Name  an Address  This depends on.. of course.. Context!
  15. 15. Factories , Repositories, Aggregates  Factories create, Repositories store  The unit of work they work on is an aggregate  The thing they create of find and hand over will be a reference to the aggregate root
  16. 16. Services  Services encapsulate... well… Services  They are not part of the core domain, but linked  Objects change into other objects
  17. 17. Layers.. and more  UI > domain model > Data access SOFTWARE INNOVATORS 17  Or.. domain model depends on nothing
  18. 18. SOFTWARE INNOVATORS 18 Refactoring towards deeper insight
  19. 19. Refactoring towards deeper insight  Use patterns when appropriate  Make Unit Tests  Better yet, do TDD  Better yet, do BDD  DRY and YAGNI  But: all a bit technical
  20. 20. Making Implicit Concepts explicit  Listen to Language  Scrutinize Awkwardness  Contemplate Contradictions  Read the Book  Try, Try again  Model the less-than-obvious: constraints, processes, commands, relations, etc.
  21. 21. SOFTWARE INNOVATORS 21 Strategic Design
  22. 22. Contents of chapter 4 as a model
  23. 23. Strategic Design: context rules!  Be aware of different contexts  Make a context map  See how different bounded contexts relate  Shared Kernel, Customer/Supplier development teams, Conformist, Separate Ways, Partner  Use an anti-corruption layer
  24. 24. Context Maps step-by-step 1. What models (or BBoM) do we know of? (draw blob each and name it.) 2. Where does each apply? (Boundary in words.) 3. Where is information exchanged? (Connect) 4. What is the relationship? (Upstream/downstream? Partner? Etc.)
  25. 25. SOFTWARE INNOVATORS 25 What has been learned since the book?
  26. 26. Highlights that Evans learned  Building blocks are overemphasized  But domain events added as a new type of block  General advice ▫ Don’t spread modeling too thin ▫ Focus on the core domain ▫ Clean, bounded context (CM steps available) ▫ Iterative process ▫ Don’t bore your domain experts
  27. 27. Domain events taken further  Greg Young has been promoting the idea of Command and Query separation
  28. 28. Techniques to explore  Exploratory Modeling (xM)  Model Driven Development environments  Language Workbenches  Naked Objects and other such platforms SOFTWARE INNOVATORS 28
  29. 29. SOFTWARE INNOVATORS 29 Quick Wrap-up
  30. 30. Summary  DDD highlights aspects of software design  It focuses on the ‘core domain’ and uses a ubiquitous language, based on a domain model  The ubiquitous language brings out flaws  A Domain Model is normally made up of certain types of building blocks  Thinks about context too: take control where and whenever possible
  31. 31. Resources for Further study  http://www.domaindrivendesign.org  Numerous articles on http://www.infoq.com  http://www.slideshare.net/devnology/unleash- your-domain-with-greg-young
  32. 32. DDD in C#  Jimmy Nilsson applied it to a C# context. His book is has an informal tone, but a bit noisy. Applying DDD and Patterns With Examples in C# and .NET
  33. 33. SOFTWARE INNOVATORS 33 Contact Rick van der Arend rvdarend@sogyo.nl 030 - 220 22 16 Web: www.sogyo.nl Blog: www.software–innovators.nl

×