I presented Domain Driven Design (and Command Query Separation) internally to my company.

1. Domain Driven Design Ryan Riley Catapult Systems, Inc.

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

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

22. Focus on the Object Model

23. Focus on Object-Oriented Design

24. Works well with other *DD methods to:

25. Reduce Complexity

27. Nouns == Classes

28. Verbs == methods, services, etc.

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

30. Classes = Job, JobBoard

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

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

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

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

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

73. Domain Driven Design Patterns (or how it works)

76. Structure

77. Behavior

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

79. Uniquely identified and tracked

80. Associated with other objects

81. Simplify

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)

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)

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

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

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

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.

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

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)

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

179. Defining characteristics:

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

181. Stateless

182. Examples:

183. Transfers

185. Becomes part of the ubiquitous language

186. Helps with decoupling

188. POCO messages

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

192. State Machines: transition from one state to another

193. Domain Model (Aggregate) defines transitions

194. Examples:

195. HTTP

197. Can help identify requirements

198. Focus on the language

199. Feel free to use patterns in other styles

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)