Domain Driven Design

2,708 views

Published on

Domain Driven Development brief overview

Published in: Technology, Business
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,708
On SlideShare
0
From Embeds
0
Number of Embeds
22
Actions
Shares
0
Downloads
122
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Domain Driven Design

  1. 1. Lalit Kale<br />e-Zest Solutions Ltd.<br />Domain Driven Design<br />
  2. 2. Problem<br />
  3. 3. Problem- Characters Involved<br />
  4. 4. Problem<br />Diverse Characters to solve one problem<br />Everybody talks in different language<br />Ultimate Result- Delivered solution is brittle and Fragile<br />
  5. 5. Everybody who are involved should talk in one Language<br />Step 1 : Agree on language terminology and definitions<br />Step 2: Call on the language expert<br />Step 3 : Use Business model to device the language<br />Solution<br />
  6. 6. Domain: “Afield of study that defines a set of common requirements, terminology, and functionality for any software program constructed to solve a problem in that field “.<br />Driven: Focused on<br />Domain Driven Development<br />
  7. 7. Domain: “Afield of study that defines a set of common requirements, terminology, and functionality for any software program constructed to solve a problem in that field “. = Problem Domain<br />Domain Model: The domain model is a rigorously organized and selective abstractionsof knowledge’<br />Domain Driven Development<br />
  8. 8. Traditional Architecture<br />Presentation<br />Business Layer<br />Infrastructure/<br />Utility/Library<br />Data Access (DAL)<br />
  9. 9. DDD Architecture<br />User Interface<br />Application Services<br />M<br />Domain Services<br />Database<br />Domain Model<br />Services<br />File<br />system<br />Tests<br />Infrastructure<br />etc<br />
  10. 10. DDD Architecture<br />User Interface<br />Application Services<br />M<br />Domain Services<br />Database<br />Domain Model<br />Services<br />File<br />system<br />Tests<br />Infrastructure<br />etc<br />
  11. 11. DDD Jargon<br /><ul><li>Conceptual
  12. 12. Ubiquitous Language
  13. 13. Bounded Contexts
  14. 14. Persistence Ignorance
  15. 15. Refactoring
  16. 16. Command Query Separation (CQS)
  17. 17. When to use DDD
  18. 18. When NOT to Use DDD
  19. 19. Patterns
  20. 20. Entities
  21. 21. Value Objects
  22. 22. Aggregate Roots
  23. 23. Object Creation Patterns
  24. 24. Repository
  25. 25. Specification
  26. 26. Domain Services
  27. 27. Modules
  28. 28. Domain Events
  29. 29. State Machines</li></li></ul><li>DDD Fundamentals<br />
  30. 30. DDD Fundamentals-Entity<br />Objects that have a distinct identity that runs through time and different representations. You also hear these called &quot;reference objects&quot;.<br />Entities are usually big things like<br />
  31. 31. DDD Fundamentals-Value Objects<br />A small simple object, like money or a date range, whose equality isn&apos;t based on identity.<br />Value Objects are usually small things (Hidden concepts in system) like<br />
  32. 32. DDD Fundamentals- Aggregate Roots<br />An Aggregate comprises of an intimately associated group of Entities and Value Objects<br />Aggregates are treated as a single unit for the purpose of persistence, and references are only allowed to the Aggregate Root<br />
  33. 33. DDD In Practice<br />
  34. 34. Without DDD<br />
  35. 35. With DDD-Code Flows<br />
  36. 36. Promotes high cohesion and low coupling <br />Easy to test domain components <br />Business (domain) logic is isolated from non-domain and infrastructure code <br />Adding/changing services does not influence the domain or other services.<br />Everybody talks on same terms<br />Advantages<br />

×