Domain Driven Design Demonstrated

1.
Domain Driven Design Demonstrated Alan Christensen @christensena Christchurch Code Camp Feb 18 2012 1

2.
What is aDomain? 2

3.
What is aDomain? • “A sphere of knowledge, inﬂuence 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 • Understandyour domain 4

12.
Domain Modeling • Understandyour domain • Model it in the code to suit the purpose and context for which it was intended 4

13.
Domain Modeling • Understandyour 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 • Understandyour 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 reﬁning “refactor to greater insight” 4

16.
Ubiquitous Language 6

17.
Ubiquitous Language • Namingis important! 6

18.
Ubiquitous Language • Namingis important! • As is a shared understanding and consistent use of terms 6

19.
Ubiquitous Language • Namingis 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 • Namingis 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

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 anidentity 10

28.
Entities • Have anidentity • Identity may be determined by a natural or assigned key (e.g. Id) 10

29.
Entities • Have anidentity • 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 anidentity • 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 • Noidentity. Can be mixed and matched 11

33.
Value objects • Noidentity. Can be mixed and matched • Equals implemented as “all ﬁelds/properties match” 11

34.
Value objects • Noidentity. Can be mixed and matched • Equals implemented as “all ﬁelds/properties match” • Immutable - replace instead of change 11

35.
Worked example • Whatdomain 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 ensureconsistency in the domain model 15

40.
Invariants • Invariants ensureconsistency in the domain model • They allow us to code with conﬁdence that invalid/unnatural states are not possible 15

41.
Invariants • Invariants ensureconsistency in the domain model • They allow us to code with conﬁdence 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 isnot really a domain concept. Invariants are the richer idea. 17

45.
Validation? • Validation isnot 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 • Persistenceis a technical concern. Not part of the domain. 18

48.
Persistence Ignorance • Persistenceis a technical concern. Not part of the domain. • Fortunately good ORM’s support Persistence Ignorance out of the box 18

49.
Persistence Ignorance • Persistenceis 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 “ﬁnd” functionality 19

52.
Repositories • Semantically just“collections” with enhanced “ﬁnd” functionality • In reality they will be the “gateway” to the persistence store 19

53.
Repositories • Semantically just“collections” with enhanced “ﬁnd” 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 entitiesonly make sense in the context of a parent entity or hierarchy 20

56.
Aggregates • Some entitiesonly make sense in the context of a parent entity or hierarchy • Nominate speciﬁc entities as Aggregate Roots 20

57.
Aggregates • Some entitiesonly make sense in the context of a parent entity or hierarchy • Nominate speciﬁc entities as Aggregate Roots • All other entities are only accessible by traversing from their aggregate roots 20

58.
Aggregates • Some entitiesonly make sense in the context of a parent entity or hierarchy • Nominate speciﬁc 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 • Notgeneral-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 DataBinding 25

64.
UI and DataBinding • Don’t try to data bind to anything in your domain model! 25

65.
UI and DataBinding • 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 DataBinding • 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 DataBinding • 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 suchas NHibernate create proxies, bypass invariants for re-hydration 26

70.
Transports/Hydration • ORMs suchas NHibernate create proxies, bypass invariants for re-hydration • Invariants mean .NET serialisation needs to be via DTO’s. 26

71.
Transports/Hydration • ORMs suchas 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 suchas 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 styleaggregates can be a natural ﬁt for document oriented databases 27

75.
NoSQL? • DDD styleaggregates can be a natural ﬁt for document oriented databases • No need for mapping! 27

76.
NoSQL? • DDD styleaggregates can be a natural ﬁt for document oriented databases • No need for mapping! • Use of event sourcing can feed same information into reporting database(s) 27

77.
NoSQL? • DDD styleaggregates can be a natural ﬁt 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 useDDD? • 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

Domain Driven Design Demonstrated

In this document