Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

DDD - What, why, how?

2,321 views

Published on

Many people who start exploring Domain-Driven Design (DDD) are wondering what it's all about. Some argue that all those implementation pattern are important. Others say that these patterns should have been excluded from the Blue Book in sake of strategic design. I mostly agree with the latter and explain why in this presentation. It was presented at the first DDD Norway meetup in Oslo, on the 1st of March 2017.

Published in: Software
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

DDD - What, why, how?

  1. 1. Alexey Zimarev Software Architect at ABAX AS, Norway DDD Norway Meetup Organiser @Zimareff alex@zimarev.com https://www.linkedin.com/in/alexeyzimarev http://zimarev.com
  2. 2. Domain-Driven Design Why, What and How
  3. 3. History of Programming
  4. 4. FORTRAN 1957 Science Math Engineering
  5. 5. LISP 1958 Lots of parenthesis
  6. 6. LISP 1958 Math AI Lambda calculus
  7. 7. COBOL Common Business- Oriented Language 1959 Business Finance Administration
  8. 8. ALGOL 1958 Computer science Found no adoption
  9. 9. Early days programmers Mathematicians Scientists Engineers Business people
  10. 10. COBOL was almost like plain English
  11. 11. Computer people took the language with least adoption among domain experts and started using it everywhere
  12. 12. Cobol only evolved to another Cobol
  13. 13. Business Still does programming
  14. 14. Waterfall Collect requirements Design Code Test Maintain
  15. 15. Book on Requirement s
  16. 16. Customer Gone missing
  17. 17. Domain- Driven Design 2003 Eric Evans
  18. 18. The Blue Book Knowledge crunching Ubiquitous language Model-driven design Implementation patterns (entity, aggregate, aggregate root, value object, strategy, domain service, domain event, repository, etc) Supple design, Refactoring towards deeper insight Strategic design (bounded context, context map, core domain, subdomains)
  19. 19. What went wrong? Strategy is hard Tactics is easier People prefer easier tasks
  20. 20. Layered Architecture
  21. 21. Domain Model Starts simple and clean
  22. 22. Domain Model Growth a little
  23. 23. Domain Model A little more
  24. 24. Domain Model Eventually…
  25. 25. Big Ball of Mud
  26. 26. “A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition” –Brian Foote and Joseph Yoder's - Big Ball of Mud - 1997
  27. 27. Big Ball of Mud Most popular architecture style Does something useful Without telling anyone how Hard to impossible to change
  28. 28. It started so well! Look, I have entities Wow, here is my aggregate root Check this, I got bunch of repositories
  29. 29. “DDD Light” Look, I have entities Wow, here is my aggregate root Check this, I got bunch of repositories That is not DDD
  30. 30. developing Ubiquitous Language within Bounded Context
  31. 31. Context is the thing The bandage was wound around the wound. We must polish the Polish. He could lead if he would get the lead. The soldier decided to desert his dessert in the desert. Since there is no time like the present, he thought it was time to present the present. http://www.mtmlinguasoft.com/context-is-everything-especially-in-translation/
  32. 32. We are linguists
  33. 33. Talk to domain experts Whiteboard Event Storming Observations Business Model Canvas BDD/Visual Language (Given-When-Then)
  34. 34. Bounded Context The place where language lives Same word might have different meaning in another context High cohesion - hard to split Speed of change - things change together
  35. 35. Layers - per context
  36. 36. Context Map
  37. 37. Core Domain
  38. 38. Core Domain Competitive advantage Absolutely critical part Distinction from competitors Problem space complexity
  39. 39. Core Domain Best resources Strong focus Good design
  40. 40. Supportive subdomain Candidate for off-the-shelf software Prefer buying versus building Candidate for CRUD Can be outsourced
  41. 41. Single model Wobbly Too big - hard to reason about Tightly coupled Hard to test Requires coordination
  42. 42. Coordination
  43. 43. Reality is different
  44. 44. Contextual models Focused Small - easier to reason about Decoupled Easy to change Enables autonomy
  45. 45. Autonomy Bounded context creates autonomy Allows teams working in parallel Little or no coordination Independent release and feedback cycle
  46. 46. –Eric Evans “DRY is inside the bounded context, NOT the whole system.”
  47. 47. DO NOT Don’t concentrate on technicalities Don’t expect the ideal model, expect many iterations Don’t over-engineer Protect context boundaries, don’t allow shortcuts and leaking abstractions from other contexts Respect and don’t ubiquitous language
  48. 48. –Eric Evans “Good design is imperfect design.”
  49. 49. DO Speak to domain experts (using their language) Crunch knowledge Find core domain Refactor towards deeper insight
  50. 50. –Alberto Brandolini “Software development is a learning process. Working software is a side effect”
  51. 51. Reading

×