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.

Introduction to Domain Driven Design

1,079 views

Published on

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

Published in: Software

Introduction to Domain Driven Design

  1. 1. Introduction to Domain-Driven Design (DDD) Christos Tsakostas Athens, 13th December 2013
  2. 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. 3. MOTIVATION
  4. 4. 4 Common Problems Monolithic Models (Big Ball of Mud) Anemic Data Models Relational-Database way of thinking Communication Difficulties
  5. 5. 5 Monolithic Models
  6. 6. 6 Anemic Domain Models (cause Memory Loss)
  7. 7. 7 Communication Difficulties Domain Expert Developer
  8. 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. 9. INTRODUCTION
  10. 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. 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. 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. 13. STRATEGIC DESIGN
  14. 14. 14 Fact For Complex Systems, most often, A Single Model Cannot Make it!
  15. 15. 15 What do we do? Multiple Models
  16. 16. 16 Strategic Design: The Result
  17. 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. 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. 19. IUCLID 19 Strategic Design – 3. Define Contexts Life Cycle Context Assessment Context Substance Context Library Context Identity and Access Context Chesar Domain
  20. 20. IUCLID 20 Strategic Design – 3. Define Contexts / Alternative Assessment & Life Cycle Context Substance Context Library Context Identity and Access Context Chesar Domain
  21. 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. 22. 9/12/2013 22 Strategic Design – 5. Model Integrity
  23. 23. 23 What if initial Strategy is proved to be wrong? It’s Human Nature…even Inevitable…
  24. 24. 24 What do we do? Redesign – Refactor. Make it Better! Initial Designs should not be Dogmas.
  25. 25. DEFINITIONS
  26. 26. 26 Domain (Problem Space) A sphere of knowledge, influence, or activity (or “The Business”)
  27. 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. 28 Problem Space vs Solution Space Domain Domain Model
  29. 29. 29 Context The setting in which a word or statement appears that determines its meaning.
  30. 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. 31 Context Map Translation Map between Bounded Contexts.
  32. 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. 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
  34. 34. 34 Data-Driven Implementation
  35. 35. 35 DDD Approach incorporating Ubiquitous Language
  36. 36. 36 DDD Approach incorporating Ubiquitous Language Put Behavior (the “What to do”), described in a Ubiquitous way, inside the Object
  37. 37. TACTICAL DESIGN
  38. 38. Inside a Bounded Context Tactical Design
  39. 39. 39 Model-Driven Design
  40. 40. 40 Data-Driven Design: An Invoice
  41. 41. 9/12/2013 41 Model-Driven Design – Invoicing Context
  42. 42. 42 Tactical Design Towards a Maintainable and Extensible Model
  43. 43. 43 Supple Design
  44. 44. Remembering Object Oriented Programming Tactical Design
  45. 45. 45 A - PIE Abstraction Polymorphism Inheritance Encapsulation
  46. 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. 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
  48. 48. 48 Law of Demeter
  49. 49. 49 Tell - Don’t Ask
  50. 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)
  51. 51. ARCHITECTURE Tactical Design
  52. 52. 52 Layered Architecture
  53. 53. 53 Dependency Inversion Principle (DIP)
  54. 54. 54 Layered Architecture based on DIP
  55. 55. 55 Hexagonal Architecture / Ports and Adapters
  56. 56. COMMAND QUERY SEPARATION Tactical Design
  57. 57. 57 Single Model
  58. 58. 58 Command Query Responsibility Segregation (CQRS)
  59. 59. 59 CQRS with Events and Different Storages
  60. 60. 60 CQRS -> Command Bus
  61. 61. DOMAIN EVENTS Tactical Design
  62. 62. 62 Domain Events / Event Sourcing
  63. 63. 63 Domain Events / Event Sourcing
  64. 64. 64 Event Sourcing
  65. 65. 65 Event Stores: A Time Travel Logging of Everything Business Intelligence
  66. 66. 66 Views / Projections Disposable Even In Memory!
  67. 67. 67 Tactical Design: Naming & Modules A.P.I. Bounded Context Domain Model Ports & Adapters
  68. 68. 68 Tactical Design: Naming & Modules Application Services Commands Events Domain Service Aggregates
  69. 69. 69 Tactical Design:Task-based UIs (Inductive UIs) Typical CRUD form Task-based
  70. 70. STRATEGIC DESIGN REVISITED
  71. 71. 71 Strategic Design - Distillation
  72. 72. 72 Distillation: An Abstract Assessment
  73. 73. 73 Bringing the Strategy Together
  74. 74. WRAP-UP
  75. 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. 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. 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

×