Domain Driven Design Demonstrated

2,917 views

Published on

Domain Driven Design Demonstrated in .NET using C# and Fluent NHibernate.

Christchurch Code Camp 2012

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

No Downloads
Views
Total views
2,917
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Domain Driven Design Demonstrated

    1. 1. Domain Driven Design Demonstrated Alan Christensen @christensena Christchurch Code Camp Feb 18 2012 1
    2. 2. What is a Domain? 2
    3. 3. What is a Domain?• “A sphere of knowledge, influence or activity”--Eric Evans 2
    4. 4. What is DDD? 3
    5. 5. What is DDD?• In order of importance: 3
    6. 6. What is DDD?• In order of importance: • Design methodology 3
    7. 7. What is DDD?• In order of importance: • Design methodology • Architectural style 3
    8. 8. What is DDD?• In order of importance: • Design methodology • Architectural style • Set of software patterns 3
    9. 9. What is DDD?• In order of importance: • Design methodology • Architectural style • Set of software patterns• “Tackling Complexity in the Heart of Software”--DDD book tagline 3
    10. 10. Domain Modeling 4
    11. 11. Domain Modeling• Understand your domain 4
    12. 12. Domain Modeling• Understand your domain• Model it in the code to suit the purpose and context for which it was intended 4
    13. 13. Domain Modeling• Understand your domain• Model it in the code to suit the purpose and context for which it was intended• Leave out details and concepts that don’t add value 4
    14. 14. Domain Modeling• Understand your domain• Model it in the code to suit the purpose and context for which it was intended• Leave out details and concepts that don’t add value• Keep refining “refactor to greater insight” 4
    15. 15. 5
    16. 16. Ubiquitous Language 6
    17. 17. Ubiquitous Language• Naming is important! 6
    18. 18. Ubiquitous Language• Naming is important!• As is a shared understanding and consistent use of terms 6
    19. 19. Ubiquitous Language• Naming is important!• As is a shared understanding and consistent use of terms• The code should use the same terms used in documents and discussion 6
    20. 20. Ubiquitous Language• Naming is important!• As is a shared understanding and consistent use of terms• The code should use the same terms used in documents and discussion• Both domain experts and developers contribute to the shared language 6
    21. 21. 7
    22. 22. 7
    23. 23. 7
    24. 24. the Welsh reads "I am not in the office at themoment. Send any work to be translated." 8
    25. 25. Onion Architecture 9
    26. 26. Entities 10
    27. 27. Entities• Have an identity 10
    28. 28. Entities• Have an identity• Identity may be determined by a natural or assigned key (e.g. Id) 10
    29. 29. Entities• Have an identity• Identity may be determined by a natural or assigned key (e.g. Id)• Equals implementation to distinguish identity normally uses key 10
    30. 30. Entities• Have an identity• Identity may be determined by a natural or assigned key (e.g. Id)• Equals implementation to distinguish identity normally uses key• Mutable - can be changed 10
    31. 31. Value objects 11
    32. 32. Value objects• No identity. Can be mixed and matched 11
    33. 33. Value objects• No identity. Can be mixed and matched• Equals implemented as “all fields/properties match” 11
    34. 34. Value objects• No identity. Can be mixed and matched• Equals implemented as “all fields/properties match”• Immutable - replace instead of change 11
    35. 35. Worked example• What domain should we use? • Inventory? • Payroll? • Share trading? 12
    36. 36. 13
    37. 37. Code demo #1• Model Driven Design • Domain Methodology • Entities and Value Objects • Invariants 14
    38. 38. Invariants 15
    39. 39. Invariants• Invariants ensure consistency in the domain model 15
    40. 40. Invariants• Invariants ensure consistency in the domain model• They allow us to code with confidence that invalid/unnatural states are not possible 15
    41. 41. Invariants• Invariants ensure consistency in the domain model• They allow us to code with confidence that invalid/unnatural states are not possible• They enforce domain rules and prevent logical fallacies 15
    42. 42. Invariants• Examples • Private setters • Required constructor/factory method parameters • Exceptions for invalid operations or invalid arguments to methods 16
    43. 43. Validation? 17
    44. 44. Validation?• Validation is not really a domain concept. Invariants are the richer idea. 17
    45. 45. Validation?• Validation is not really a domain concept. Invariants are the richer idea.• Validation should be done outside the domain to prevent invariants from ever occurring (exceptions are for exceptions) 17
    46. 46. Persistence Ignorance 18
    47. 47. Persistence Ignorance• Persistence is a technical concern. Not part of the domain. 18
    48. 48. Persistence Ignorance• Persistence is a technical concern. Not part of the domain.• Fortunately good ORM’s support Persistence Ignorance out of the box 18
    49. 49. Persistence Ignorance• Persistence is a technical concern. Not part of the domain.• Fortunately good ORM’s support Persistence Ignorance out of the box• Transactions can be packaged in a “Unit of Work” concept 18
    50. 50. Repositories 19
    51. 51. Repositories• Semantically just “collections” with enhanced “find” functionality 19
    52. 52. Repositories• Semantically just “collections” with enhanced “find” functionality• In reality they will be the “gateway” to the persistence store 19
    53. 53. Repositories• Semantically just “collections” with enhanced “find” functionality• In reality they will be the “gateway” to the persistence store• Repositories are the main mechanism for Persistence Ignorance 19
    54. 54. Aggregates 20
    55. 55. Aggregates• Some entities only make sense in the context of a parent entity or hierarchy 20
    56. 56. Aggregates• Some entities only make sense in the context of a parent entity or hierarchy• Nominate specific entities as Aggregate Roots 20
    57. 57. Aggregates• Some entities only make sense in the context of a parent entity or hierarchy• Nominate specific entities as Aggregate Roots• All other entities are only accessible by traversing from their aggregate roots 20
    58. 58. Aggregates• Some entities only make sense in the context of a parent entity or hierarchy• Nominate specific entities as Aggregate Roots• All other entities are only accessible by traversing from their aggregate roots• Inter-aggregate relationships via queries/ lookups on repositories 20
    59. 59. 21
    60. 60. Code demo #2• Repositories• Unit of Work• Fluent NHibernate AutoMapping• Session per Request 22
    61. 61. 23
    62. 62. Domain Services• Not general-purpose “services” (overloaded term)• Repository/UoW aware (entities are not)• Able to coordinate business processes• Most logic should still be inside entity and value objects (Domain Model) 24
    63. 63. UI and Data Binding 25
    64. 64. UI and Data Binding• Don’t try to data bind to anything in your domain model! 25
    65. 65. UI and Data Binding• Don’t try to data bind to anything in your domain model!• Bind to “view models”, tailored to your view (MVC/MVP/MVVM) 25
    66. 66. UI and Data Binding• Don’t try to data bind to anything in your domain model!• Bind to “view models”, tailored to your view (MVC/MVP/MVVM)• Read operations: Use tools like AutoMapper to map to view models 25
    67. 67. UI and Data Binding• Don’t try to data bind to anything in your domain model!• Bind to “view models”, tailored to your view (MVC/MVP/MVVM)• Read operations: Use tools like AutoMapper to map to view models• Write operations: Intention/behaviour oriented. Command processor pattern works well 25
    68. 68. Transports/Hydration 26
    69. 69. Transports/Hydration• ORMs such as NHibernate create proxies, bypass invariants for re-hydration 26
    70. 70. Transports/Hydration• ORMs such as NHibernate create proxies, bypass invariants for re-hydration• Invariants mean .NET serialisation needs to be via DTO’s. 26
    71. 71. Transports/Hydration• ORMs such as NHibernate create proxies, bypass invariants for re-hydration• Invariants mean .NET serialisation needs to be via DTO’s.• DTO’s are best not as domain model clones! As with UI viewmodels, tailor for purpose. 26
    72. 72. Transports/Hydration• ORMs such as NHibernate create proxies, bypass invariants for re-hydration• Invariants mean .NET serialisation needs to be via DTO’s.• DTO’s are best not as domain model clones! As with UI viewmodels, tailor for purpose. 26
    73. 73. NoSQL? 27
    74. 74. NoSQL?• DDD style aggregates can be a natural fit for document oriented databases 27
    75. 75. NoSQL?• DDD style aggregates can be a natural fit for document oriented databases• No need for mapping! 27
    76. 76. NoSQL?• DDD style aggregates can be a natural fit for document oriented databases• No need for mapping!• Use of event sourcing can feed same information into reporting database(s) 27
    77. 77. NoSQL?• DDD style aggregates can be a natural fit for document oriented databases• No need for mapping!• Use of event sourcing can feed same information into reporting database(s)• If using relational as dual use e.g. reporting, consider the change resistance 27
    78. 78. Fashions &Developments 28
    79. 79. Fashions & Developments• CQRS 28
    80. 80. Fashions & Developments• CQRS• Micro-ORMs 28
    81. 81. Fashions & Developments• CQRS• Micro-ORMs• Repository pattern? 28
    82. 82. Summary• Modeling Driven• This means designing and writing code that • expresses the domain logic • follows/enforces the domain rules • uses the domain language • databases, UI, infrastructure, etc are outside the domain 29
    83. 83. 30
    84. 84. Should I use DDD?• DDD over engineered for simple CRUD or mostly data oriented applications• Best suited to complex, behaviourally oriented applications• However, many of the ideas and patterns are useful in all sorts of projects 31
    85. 85. Other DDD concepts• Factories• Bounded Contexts• Anti-corruption Layers• Domain Events 32
    86. 86. Umpire Scorecard Over Over Player PlayerDelivery Run No-Ball Team Wide Innings Out Dismissal Crease Bowling SpellBoundary Country LBW Scorecard Bat-Pad MatchStumping Fall-of-Wickets LightWeather 33
    87. 87. Umpire Scorecard Over Over Player PlayerDelivery Run No-Ball Team Wide Innings Out Dismissal Crease Bowling SpellBoundary Country LBW Scorecard Bat-Pad MatchStumping Fall-of-Wickets LightWeather 33
    88. 88. References• DDD Quickly book on InfoQ bit.ly/dddquickly• Think DDD (Jak Charlton) bit.ly/thinkdddbook• Onion Architecture bit.ly/onionarch• Martin Fowler on Aggregates and NoSQL bit.ly/aggregates-nosql• My example code: github.com/christensena/DDDIntro 34
    89. 89. Alan Christensen @christensena35

    ×