1.
Domain Driven Design<br />Ryan Riley<br />Catapult Systems, Inc.<br />

2.
Domain Driven Design<br />When you remember that DDD is really just “OO software done right”, it becomes more obvious<br />that strong OO experience will also stand you in good stead when approaching DDD.<br />- Jak Charlton, Domain Driven Design Step-by-Step<br />

3.
Domain Driven Design<br />Agenda<br /><ul><li>Patterns

4.
Entities

5.
Value Objects

6.
Aggregate Roots

7.
Object Creation Patterns

8.
Repository

9.
Specification

10.
Domain Services

11.
Modules

12.
Domain Events

13.
State Machines

14.
Conceptual

15.
Ubiquitous Language

16.
Bounded Contexts

17.
Persistence Ignorance

18.
Refactoring

19.
Command Query Separation

20.
When to use DDD</li></li></ul><li>Domain Driven Design<br />Conceptual Elements<br />(or what it means)<br />

21.
Domain Driven Design<br />Domain Driven Design<br /><ul><li>Domain First

22.
Focus on the Object Model

23.
Focus on Object-Oriented Design

24.
Works well with other *DD methods to:

25.
Reduce Complexity

26.
Increase Maintainability</li></li></ul><li>Domain Driven Design<br />Ubiquitous Language<br /><ul><li>Model the language used by your domain experts

27.
Nouns == Classes

28.
Verbs == methods, services, etc.

29.
Example: A Hiring Specialist may post Jobs to the Job Board.

30.
Classes = Job, JobBoard

31.
Actions = JobBoard.PostJob(Job)</li></li></ul><li>Domain Driven Design<br />Bounded Contexts<br /><ul><li>One of many integration patterns

32.
Continuous Integration

33.
Shared Kernel

34.
Customer / Supplier

35.
Conformist

36.
Anticorruption Layer

37.
Separate Ways

38.
More than One Ubiquitous Language

39.
Applicant terminology

40.
Hiring Specialist terminology

41.
Department terminology</li></li></ul><li>Domain Driven Design<br />Persistence Ignorance<br /><ul><li>Why is this important?

42.
Model-driven, not data-driven

43.
Focus on the domain, not the data structure

44.
Quickly swap out repositories for testing, POC, etc.

45.
How?

46.
Plain Old CLR Objects (POCO)

47.
Repository pattern (abstract the data access)

48.
Aggregate Roots

49.
More on this in a minute</li></li></ul><li>Domain Driven Design<br />Persistence Ignorance<br />UI<br />Application /Service<br />Domain<br />Data Access<br />Infrastructure<br />

50.
Domain Driven Design<br />Refactoring<br /><ul><li>“Refactor to deeper insights”

51.
Include your domain experts in your refactoring

52.
Refactor your ubiquitous language 1st, your code 2nd

53.
This doesn’t mean refactor for greater reusability

54.
Example: benefit disbursements

55.
Initially used Retro disbursements for final partial-month payments

56.
Realized that these required different actions

57.
Symptom: confusion around the name Retro when talking about Final Partial Payments</li></li></ul><li>Domain Driven Design<br />Command Query Separation<br />User Interface<br />Commands<br />Query / Reporting<br />Service<br />Commands<br />Domain<br />Events<br />Events<br />Infrastructure<br />Event Store<br />

58.
Domain Driven Design<br />Command Query Separation<br /><ul><li>Origins – Eiffel language

59.
Use for Distributed architectures

60.
Move from class method level to the architectural level

61.
Separate Bounded Contexts for reading and writing

62.
Write == Commands == Change state and return nothing

63.
Read == Queries == Pure functions that do not change state

64.
Optimize each side differently

65.
Focus on:

66.
Event-Driven Architecture with Domain Events

67.
State Machines

68.
Allows easy transitions to:

69.
Messaging services

70.
Asynchronous processing

71.
Massive scalability</li></li></ul><li>Domain Driven Design<br />When to use DDD<br /><ul><li>Now! (Not really)

72.
Fits approximately 5% of development project needs</li></ul>DDD is a software methodology suited to a particular kind of application – one where there is<br />significant complexity, and there is a significant focus on a well defined business model.<br />- Jak Charlton, Domain Driven Design Step-by-Step<br />

73.
Domain Driven Design<br />Patterns<br />(or how it works)<br />

74.
Domain Driven Design<br />Entities<br />A behavioral approach mandates the assignment of responsibilities first. Only when you are satisfied with the distribution of responsibilities among your objects are you ready to make a decision about what they need to know…. Behavior is the only criterion we use to differentiate among objects.<br /><ul><li>Dr. David West, Object Thinking</li></ul>When data is the center piece of your object, you assign data to objects before saying what they do. Descriptions of data don’t tell you squat about your objects.<br />- Rocky Lhotka, http://www.theserverside.net/tt/articles/showarticle.tss?id=BusinessObjects<br />

75.
Domain Driven Design<br />Entities, cont.<br /><ul><li>The Domain Model pattern:

76.
Structure

77.
Behavior

78.
No persistence behavior (i.e. Active Record)

79.
Uniquely identified and tracked

80.
Associated with other objects

81.
Simplify

82.
Remove unnecessary associations</li></li></ul><li>Domain Driven Design<br />Value Objects<br /><ul><li>Nothing special (no identity)

83.
Don’t confuse with value type

84.
Immutable

85.
One instance can be used for in multiple entities

86.
Examples:

87.
Money

88.
Address (usually)

89.
Codes</li></li></ul><li>Domain Driven Design<br />Aggregate Roots<br /><ul><li>A complete and meaningful representation

90.
Based on a single root (Entity)

91.
Some entities or value objects don’t mean much alone

92.
Maintains state for a collection of objects

93.
Serves as a boundary between the objects inside and those outside

94.
Simplifies access to the associated objects

95.
The root has global identity and maintains invariants

96.
Aggregates may be nested

97.
Don’t go too deep!

98.
Examples:

99.
Job Board (Job)

100.
Job (Skill, Applicant)

101.
Applicant (Applicant Skill)</li></li></ul><li>Domain Driven Design<br />Object Creation Patterns<br /><ul><li>Aid in object creation

102.
Entities and Value Objects should ALWAYS be valid!

103.
Constructors

104.
Factory

105.
Simple Factory (Factory Method moved up to its own class)

106.
Factory Method (static method)

107.
Abstract Factory (composes from parts via inheritance)

108.
Builder

109.
Fluent Interfaces

110.
Example: String Builder

111.
Other Gang of Four patterns</li></li></ul><li>Domain Driven Design<br />Repository<br /><ul><li>Abstraction over data access

112.
Acts as a collection of Aggregate Roots

113.
Various approaches:

114.
Repository per Aggregate (very explicit)

115.
Generic Repository

116.
Repository per aggregate built upon Generic Repository Strategy

117.
Generic Repository with Specifications

118.
Used for querying and adding/removing

119.
Some implementations also add an Update

120.
Generally used along with a Unit of Work (e.g. DataContext)</li></li></ul><li>Domain Driven Design<br />Repository per Aggregate<br /><ul><li>Explicit query methods:

121.
GetById(int id)

122.
GetByName(string name)

123.
GetByCityAndState(City city, State state)

124.
AddApplicant(Applicant person)

125.
Pros:

126.
Very explicit and intentional interface so it reads better

127.
Restrict data access to what you want to allow developers

128.
Can more easily optimize each query

129.
Cons:

130.
Very manual process to create

131.
Cannot reuse methods for other purposes

132.
Extension requires editing the class</li></li></ul><li>Domain Driven Design<br />Generic Repository<br /><ul><li>Generic, open query methods:

133.
GetByKey<TKey>(TKey key)

134.
Query<T>(Expression<Func<T>> query)

135.
Insert<T>(T entity)

136.
Delete<T>(T entity)

137.
Update<T>(T entity) ?

138.
Pros:

139.
Very re-usable; write once, use everywhere

140.
Easy to code-gen for extension using partial classes

141.
More directly mimics database operations against a table

142.
Cons:

143.
Not intentional (Expressions?!)

144.
Little control over what happens on insert, delete, etc.

145.
Exposes methods you may not want exposed</li></li></ul><li>Domain Driven Design<br />Repository per Aggregate w/ Generic Strategy<br /><ul><li>Mix the best of both worlds:

146.
GetById(int id) : Query<Person>(p => p.Id == id)

147.
GetByName(string name) : Query<Person>(p => p.Name == name)

148.
Add(Person person) : Insert<Person>(person)

149.
Pros:

150.
Very explicit and intentional interface so it reads better

151.
Restrict data access to what you want to allow developers

152.
Can more easily optimize each query

153.
Standardize data access mechanics

154.
Simplify query construction in the repository

155.
Easier to swap out persistence technology (database / in-memory)

156.
Composition over Inheritance

157.
Cons:

158.
More code than Generic Repository

159.
More moving pieces</li></li></ul><li>Domain Driven Design<br />Generic Repository with Specifications<br /><ul><li>Generic functionality with explicit query functionality:

160.
Query<T>(ISpecification<T> specification)

161.
Add<T>(T entity)

162.
Pros:

163.
Extremely intention revealing

164.
Same reusability as Generic Repository

165.
Extend by creating new specifications

166.
Specifications can be used for more than querying (e.g. rules, etc.)

167.
Cons:

168.
Add, Remove, etc. may still be limited(but you probably shouldn’t do much else there anyway)

169.
May be difficult to tie into your ORM(ExpressionVisitorreq’d for L2S or EF)

170.
What is a Specification?!</li></li></ul><li>Domain Driven Design<br />Specification<br /><ul><li>Simple interface for defining criteria:

171.
IsSatisfiedBy(T entity)

172.
Similar to the Query Object pattern

173.
Very intention revealing

174.
Very easy to test

175.
Easy to chain together for more complex queries:

176.
CompoiteSpecification: And, Or, Not

177.
LINQPad uses PredicateBuilder for a similar effect

178.
http://www.lostechies.com/blogs/chrismissal/archive/2009/09/10/using-the-specification-pattern-for-querying.aspx</li></li></ul><li>Domain Driven Design<br />Domain Services<br /><ul><li>Do not confuse with Application Services

179.
Defining characteristics:

180.
Actions that do not fit within an entity or aggregate

181.
Stateless

182.
Examples:

183.
Transfers

184.
Calculators</li></li></ul><li>Domain Driven Design<br />Modules<br /><ul><li>Break up your domain to reduce complexity

185.
Becomes part of the ubiquitous language

186.
Helps with decoupling

187.
Aids in extensibility</li></li></ul><li>Domain Driven Design<br />Domain Events (CQS)<br /><ul><li>These are not delegate events

188.
POCO messages

189.
IPublish<TEvent> and IHandle<TEvent>

190.
Domain Models (Aggregates) publish events instead of saving to the database

191.
Eventual consistency (just like every other model)</li></li></ul><li>Domain Driven Design<br />State Machines (CQS)<br /><ul><li>In CQS, you don’t change state, you publish changes

192.
State Machines: transition from one state to another

193.
Domain Model (Aggregate) defines transitions

194.
Examples:

195.
HTTP

196.
Stateless</li></li></ul><li>Domain Driven Design<br />Summary<br /><ul><li>Useful for very difficult and complex domains

197.
Can help identify requirements

198.
Focus on the language

199.
Feel free to use patterns in other styles

200.
Add Command Query Separation for distributed systems</li></li></ul><li>Domain Driven Design<br />Questions?<br />

201.
Domain Driven Design<br />Resources<br /><ul><li>Books

202.
Domain Driven Design: Tackling Complexity in the Heart of Software

203.
Applying Domain Driven Design and Patterns

204.
Domain Driven Design Quickly (abbr. version of above)

205.
Domain Driven Design Step-by-Step

206.
ASP.NET MVC in Action

207.
Blogs

208.
Eric Evans

209.
Jimmy Nilsson

210.
Casey Charlton

211.
Greg Young (Distributed DDD/CQS)</li>