Domain Driven Design Demonstrated

  • 1,923 views
Uploaded on

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

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

Christchurch Code Camp 2012

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,923
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
4

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    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

Transcript

  • 1. Domain Driven Design Demonstrated Alan Christensen @christensena Christchurch Code Camp Feb 18 2012 1
  • 2. What is a Domain? 2
  • 3. What is a Domain?• “A sphere of knowledge, influence or activity”--Eric Evans 2
  • 4. What is DDD? 3
  • 5. What is DDD?• In order of importance: 3
  • 6. What is DDD?• In order of importance: • Design methodology 3
  • 7. What is DDD?• In order of importance: • Design methodology • Architectural style 3
  • 8. What is DDD?• In order of importance: • Design methodology • Architectural style • Set of software patterns 3
  • 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. Domain Modeling 4
  • 11. Domain Modeling• Understand your domain 4
  • 12. Domain Modeling• Understand your domain• Model it in the code to suit the purpose and context for which it was intended 4
  • 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. 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. 5
  • 16. Ubiquitous Language 6
  • 17. Ubiquitous Language• Naming is important! 6
  • 18. Ubiquitous Language• Naming is important!• As is a shared understanding and consistent use of terms 6
  • 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. 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. 7
  • 22. 7
  • 23. 7
  • 24. the Welsh reads "I am not in the office at themoment. Send any work to be translated." 8
  • 25. Onion Architecture 9
  • 26. Entities 10
  • 27. Entities• Have an identity 10
  • 28. Entities• Have an identity• Identity may be determined by a natural or assigned key (e.g. Id) 10
  • 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. 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. Value objects 11
  • 32. Value objects• No identity. Can be mixed and matched 11
  • 33. Value objects• No identity. Can be mixed and matched• Equals implemented as “all fields/properties match” 11
  • 34. Value objects• No identity. Can be mixed and matched• Equals implemented as “all fields/properties match”• Immutable - replace instead of change 11
  • 35. Worked example• What domain should we use? • Inventory? • Payroll? • Share trading? 12
  • 36. 13
  • 37. Code demo #1• Model Driven Design • Domain Methodology • Entities and Value Objects • Invariants 14
  • 38. Invariants 15
  • 39. Invariants• Invariants ensure consistency in the domain model 15
  • 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. 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. Invariants• Examples • Private setters • Required constructor/factory method parameters • Exceptions for invalid operations or invalid arguments to methods 16
  • 43. Validation? 17
  • 44. Validation?• Validation is not really a domain concept. Invariants are the richer idea. 17
  • 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. Persistence Ignorance 18
  • 47. Persistence Ignorance• Persistence is a technical concern. Not part of the domain. 18
  • 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. 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. Repositories 19
  • 51. Repositories• Semantically just “collections” with enhanced “find” functionality 19
  • 52. Repositories• Semantically just “collections” with enhanced “find” functionality• In reality they will be the “gateway” to the persistence store 19
  • 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. Aggregates 20
  • 55. Aggregates• Some entities only make sense in the context of a parent entity or hierarchy 20
  • 56. Aggregates• Some entities only make sense in the context of a parent entity or hierarchy• Nominate specific entities as Aggregate Roots 20
  • 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. 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. 21
  • 60. Code demo #2• Repositories• Unit of Work• Fluent NHibernate AutoMapping• Session per Request 22
  • 61. 23
  • 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. UI and Data Binding 25
  • 64. UI and Data Binding• Don’t try to data bind to anything in your domain model! 25
  • 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. 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. 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. Transports/Hydration 26
  • 69. Transports/Hydration• ORMs such as NHibernate create proxies, bypass invariants for re-hydration 26
  • 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. 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. 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. NoSQL? 27
  • 74. NoSQL?• DDD style aggregates can be a natural fit for document oriented databases 27
  • 75. NoSQL?• DDD style aggregates can be a natural fit for document oriented databases• No need for mapping! 27
  • 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. 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. Fashions &Developments 28
  • 79. Fashions & Developments• CQRS 28
  • 80. Fashions & Developments• CQRS• Micro-ORMs 28
  • 81. Fashions & Developments• CQRS• Micro-ORMs• Repository pattern? 28
  • 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. 30
  • 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. Other DDD concepts• Factories• Bounded Contexts• Anti-corruption Layers• Domain Events 32
  • 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. 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. 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. Alan Christensen @christensena35