3. Well versed full stack

5. Large whitelabel clients

6. Bursty traffic – Lady Gaga, EA, Gatorade

9. Often have an anemic domain model, scattered logic

10. Hockey stick function – fast initial growth, increasingly difficult to extend over time

12. Existing monolithic applications

13. Environments with excessive coupling or dependencies

17. High coupling to neighboring layers

18. Coupled persistence

19. Dependencies on host frameworks

21. Application

22. Domain

24. Modeling is often data driven, not behavior driven

25. Models / entities are often coupled to conventions and dependencies of the host framework

27. Fast time to market

28. Request / response + rendering

30. Conventions, practices and dependencies should grow with and adapt to that also

33. Configuration management

35. Piggyback off known contracts eg. cache['something']

36. Deprecate framework specific references in code

37. Prefer SomeApp.cache to Rails.cache etc.

39. Spawned a new project, with yet another set of conventions

41. Extreme self-discipline, from everyone

42. Business Process Model skills is required

45. Push for a common language – dev, product + biz

47. It'll be enhanced with new concepts

48. Weed out vague / deprecated elements

49. Refactorings at this level is often overlooked

51. Refactor to deeper insights

52. Extract hidden concepts – look for edge cases, policies etc.

53. In cooperation with domain experts

54. Refactor your domain first, code second

57. Distribute responsibilities first

58. Then decide what each entity needs to know

61. Some developers don't communicate well

62. Snapshot thoughts to wiki != fun

64. Concerned with features

65. Concerned with cash flow

68. Not factoring clued up domain experts into projects

69. Shielding departments from each other – us VS them

70. Visual communication.Whiteboards ? Diagrams ?

71. Domain discussions encouraged ? Shot down ?

73. But never referenced in an implementation

75. Over time, this leads to breakthroughs

76. Less edge cases

77. Ability to handle offline process programatically

79. Exceptions

81. Do include business errors in your domain

82. Define strategies for offline or programatic handling

89. Colorful speech

90. “ A valid tax invoice for taxable sales that totals x”

92. Refine statement ...

93. Agree on statement ...

94. repeat

96. Stakeholders

98. Test code

99. Discussions and meetings

100. Specs / diagrams

101. Documentation

103. Invoice, transaction, business, user, expense etc.

104. Value object if there's no identity.Reusable and immutable

106. “ A transaction between businesses generates an invoice.”

107. @business.sells(2, product, other_biz)

113. Focus on the domain, not data structure

114. Delegate storage to a repository

116. Published to your whole stack

117. Eventual consistency

119. Bypass persistence entirely – force ready-only mode

120. @record.attributes #=> value object

122. Invoice.find(1) #=> entity by identity

123. Invoice.find_by_refr(x) #=> dynamic and explicit query methods

127. Not expected to return a result

128. Should be idempotent

129. Should expire itself when not processed in a timeframe

130. Yields an event stream through interaction with the domain when processed instead

132. Try to signal the intent of a change

133. Wrap InvoiceChanged in a module

135. Thus properties should never be changed

137. Spinal cord is the ESB

138. Brain is the event listener

139. Brain is the event processor

141. Consumption

142. Processing

144. Async messaging

145. Granular events

147. No centralized control

154. Other than a guarantee it's been received

155. Should be idempotent / not reprocessed

157. PUT /invoice/1

158. DESTROY /invoice/1

160. GET /invoices

161. Serve from an eventually consistent reporting DB

163. 95% read, 5% write

164. System upgrade required

166. Disable all write services + related features

167. Continue serving requests

171. They keep histories

172. No updates, no deletes

173. Work is always auditable

174. Totals is always based on history

176. UPDATE

177. Delete

179. #update_line_item_quantity

182. Allows for compensation on multiple updates

183. Entity state is driven exclusively from this

185. Aggregates domain events

186. Feeds into a reporting database

188. Audit log store

189. Reporting database

191. at all times

192. We do guarantee that it'll be consistent eventually

193. Relaxed consistency is often acceptable

196. Measure propogation and flag SLA violations

200. Never block a write on waiting for data – it's given

201. Can use fast disks for write oriented services

202. Cache read tier ftw!

203. Formal state changes == better cache invalidation

206. Layered architectured == easy to swap out layers

207. Arrays to mock queue infrastructure

208. Behavior driven testing

209. Assert resulting events or errors

217. Understand the protocol

218. Client support

219. Durability and failover requirements

220. Publish / subscribe is preferred

222. Data types not always harmonized – accept that

224. Individual systems can modify their internal structures, providing we update our mapping layer

225. Useful if we have foreign messages (via API) to push in our stack as well – just coerce to the internal representation

227. Version backward incompatible changes

229. Allows for keeping old + new messages – no loss

230. Thin and temp. translator to pop messages off the old queue, translate / coerce them, push to the new one

232. Consumer required to lookup any additional information required

234. Loosely coupled – no additional service interactions

235. Watch out for size – Amazon SQS is limited to 8k

237. Enforcing SLAs

239. Destination system

240. /rails/user/234/session_dssasdadas/controller/action

241. Consider a “touch” mecanism – history of systems the

242. message has passed through