Domain Driven Design Demonstrated in .NET using C# and Fluent NHibernate. Christchurch Code Camp 2012

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 the
moment. 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 Player
Delivery Run
No-Ball Team
Wide Innings
Out Dismissal
Crease Bowling Spell
Boundary Country
LBW Scorecard
Bat-Pad Match
Stumping Fall-of-Wickets
Light
Weather
33

87. Umpire Scorecard
Over Over
Player Player
Delivery Run
No-Ball Team
Wide Innings
Out Dismissal
Crease Bowling Spell
Boundary Country
LBW Scorecard
Bat-Pad Match
Stumping Fall-of-Wickets
Light
Weather
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
@christensena
35