Introduction to Domain Driven Design
•10 likes•1,734 views
Report
Share
Download to read offline
An Introduction to Domain Driven Design focusing on the concepts of Bounded Context, Strategic & Tactical Design, CQRS, Ubiquitous Language, Hexagonal Architecture, Event Sourcing, Task - based UIs
More Related Content
What's hot
What's hot(20)
Viewers also liked
Viewers also liked(20)
Similar to Introduction to Domain Driven Design
Similar to Introduction to Domain Driven Design(20)
Recently uploaded
Recently uploaded(20)
Introduction to Domain Driven Design
- 1. Introduction to Domain-Driven Design (DDD) Christos Tsakostas Athens, 13th December 2013
- 2. 2 Contents Motivation Introduction Strategic Design Tactical Design - Model-Driven Design - Supple Design and OOP - Techniques (CQRS, ES, EDA) Strategic Design Revisited - Distillation - Bringing the Strategy together Wrap-Up
- 3. MOTIVATION
- 4. 4 Common Problems Monolithic Models (Big Ball of Mud) Anemic Data Models Relational-Database way of thinking Communication Difficulties
- 6. 6 Anemic Domain Models (cause Memory Loss)
- 7. 7 Communication Difficulties Domain Expert Developer
- 8. 8 DDD Alternative Monolithic Data Models (Big Ball of Mud) Anemic Data Models Relational-Database way of thinking Communication Difficulties Smaller Independent Domain Models / Integration Rich Behavior Objects (OOP done right) Persistence Ignorance Ubiquitous Language
- 9. INTRODUCTION
- 10. 10 What is DDD? It is an Approach to develop software for - Complex needs - Evolving models It is Not a technology or a methodology It is a Way of Thinking
- 11. 11 Brief History of DDD Eric Evans – 2003 DDD Community (http:// www.domaindrivendesign.org) Jimmy Nilson – 2006 Greg Young – 2008 / 2013 Vaughn Vernon – 2013 P:PubTechnical_documentationDomain Driven Design (DDD)
- 12. 12 The Business Value of DDD 1. The organization gains a useful model of its domain. 2. A refined, precise definition and understanding of the business is developed. 3. Domain experts contribute to software design. 4. A better user experience is gained. 5. Clean boundaries are placed around pure models. 6. Enterprise architecture is better organized. 7. Agile, iterative, continuous modeling is used. 8. New tools, both strategic and tactical, are employed.
- 13. STRATEGIC DESIGN
- 14. 14 Fact For Complex Systems, most often, A Single Model Cannot Make it!
- 15. 15 What do we do? Multiple Models
- 16. 16 Strategic Design: The Result
- 17. 17 Strategic Design – 1. Define the Domain & Identify Subdomains Life Cycle Assessment Substance Library Identity and Access Subdomain Subdomain Subdomain Subdomain Subdomain Chesar Domain IUCLID
- 18. 18 Strategic Design – 2. Characterize Subdomains Life Cycle Assessment Substance Library Identity and Access Supporting Subdomain Generic Subdomain Supporting Subdomain Generic Subdomain Core Domain IUCLID Chesar Domain
- 19. IUCLID 19 Strategic Design – 3. Define Contexts Life Cycle Context Assessment Context Substance Context Library Context Identity and Access Context Chesar Domain
- 20. IUCLID 20 Strategic Design – 3. Define Contexts / Alternative Assessment & Life Cycle Context Substance Context Library Context Identity and Access Context Chesar Domain
- 21. IUCLID 21 Strategic Design – 4. Make Contexts Bounded with Context Maps Life Cycle Context Assessment Context Substance Context Library Context Identity and Access Context Chesar Domain
- 22. 9/12/2013 22 Strategic Design – 5. Model Integrity
- 23. 23 What if initial Strategy is proved to be wrong? It’s Human Nature…even Inevitable…
- 24. 24 What do we do? Redesign – Refactor. Make it Better! Initial Designs should not be Dogmas.
- 25. DEFINITIONS
- 26. 26 Domain (Problem Space) A sphere of knowledge, influence, or activity (or “The Business”)
- 27. 27 Domain Model (Solution Space) A system of abstractions that: •Describes selected aspects of a domain and •Can be used to solve problems related to that domain.
- 28. 28 Problem Space vs Solution Space Domain Domain Model
- 29. 29 Context The setting in which a word or statement appears that determines its meaning.
- 30. 30 Bounded Context A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable.
- 31. 31 Context Map Translation Map between Bounded Contexts.
- 32. 32 Ubiquitous Language A language structured around the domain model. Used by all team members, within a bounded context, to connect all the activities of the team with the software. NOT universal!
- 33. 33 Ubiquitous Language - An Example Requirements for “Customer” •Change Personal Name •Set Postal Address •Relocate to Postal Address •Change Home Telephone •Disconnect Home Telephone •Set Primary Email Address •Set Secondary Email Address
- 35. 35 DDD Approach incorporating Ubiquitous Language
- 36. 36 DDD Approach incorporating Ubiquitous Language Put Behavior (the “What to do”), described in a Ubiquitous way, inside the Object
- 37. TACTICAL DESIGN
- 38. Inside a Bounded Context Tactical Design
- 40. 40 Data-Driven Design: An Invoice
- 41. 9/12/2013 41 Model-Driven Design – Invoicing Context
- 42. 42 Tactical Design Towards a Maintainable and Extensible Model
- 43. 43 Supple Design
- 44. Remembering Object Oriented Programming Tactical Design
- 46. 46 S.O.L.I.D. Single Responsibility Principle (SRP) Open / Closed Principle (OCP) Liskov Substitution Principle (LSP) Interface Segregation Principle (ISP) Dependency Inversion Principle (DIP)
- 47. 9/12/2013 47 Loose Coupling and High Cohesion Decrease Coupling Increase Cohesion Eliminate Inappropriate Intimacy The Law of Demeter Tell, Don’t Ask Say it Once and Only Once
- 49. 49 Tell - Don’t Ask
- 50. 50 Design Patterns Creational (i.e. Abstract Factory, Singleton) Structural (i.e. Adapter, Decorator, Proxy) Behavioral (i.e. Observer or Publish / Subscribe, Visitor) Concurrency (i.e. Thread Pool, Event-based Asynchronous)
- 53. 53 Dependency Inversion Principle (DIP)
- 54. 54 Layered Architecture based on DIP
- 55. 55 Hexagonal Architecture / Ports and Adapters
- 56. COMMAND QUERY SEPARATION Tactical Design
- 57. 57 Single Model
- 58. 58 Command Query Responsibility Segregation (CQRS)
- 59. 59 CQRS with Events and Different Storages
- 60. 60 CQRS -> Command Bus
- 62. 62 Domain Events / Event Sourcing
- 63. 63 Domain Events / Event Sourcing
- 65. 65 Event Stores: A Time Travel Logging of Everything Business Intelligence
- 66. 66 Views / Projections Disposable Even In Memory!
- 67. 67 Tactical Design: Naming & Modules A.P.I. Bounded Context Domain Model Ports & Adapters
- 68. 68 Tactical Design: Naming & Modules Application Services Commands Events Domain Service Aggregates
- 69. 69 Tactical Design:Task-based UIs (Inductive UIs) Typical CRUD form Task-based
- 71. 71 Strategic Design - Distillation
- 72. 72 Distillation: An Abstract Assessment
- 73. 73 Bringing the Strategy Together
- 74. WRAP-UP
- 75. 75 Wrap-Up: Strategy •In certain cases, one Model cannot make it •Multiple Models – Integration with Strategic Design •Ubiquitous Language in Model, Code, Spoken & Written Language •Be a Good Listener – Understand the Problem Space •The “worst” Domain Expert is the Best in the World compared to us •The obvious is not adequate. Focus on Exceptions •How would / does the Domain function Without Computers? •Initial Analysis and Design are Not Dogmas – Knowledge comes Slowly Redesign
- 76. 76 Wrap-Up: Tactics •Model-Driven Design as OOP done right •Focus on What instead of How •Focus on Behavior (hidden in Verbs) instead of Data (hidden in Nouns) •Be familiar with, Design Patterns and Principles •Command Query Responsibility Segregation •Event – Driven Architecture •Event Stores •Hexagonal Architecture / Ports & Adapters Refactor
- 77. 77 Strategic, Tactical, DDD, OOP, CQRS, UI, ES, EDA, …. For the things we have to learn before we can do them, we learn by doing them. Aristotle