1. Application Architecture
for Enterprise
Win Store Apps Mar, 30, 2013
@atsukanrock
with DDD Pattern Room metro Tokyo

2. @atsukanrock
http://d.hatena.ne.jp/atsukanrock/
Enterprise Application Architect
になりたい
DDD Lover

3. What customers
need is...
顧客が求めるもの

4. Win8＝
業務システム
http://wp.techtarget.itmedia.co.jp/contents/?cid=12250

5. すなわち

6. Enterprise App

7. Why App Arch?

8. Team Development

9. みんなの力を
ひとつに

10. はいはいワロスワロス
なるわけないｗ

11. はい、そうですね

12. メンバーが
思い思いに
開発すると

13. スパゲッティ

14. デスマ

15. 防ぐために
あるのが

17. 用語定義
※オレオレ定義

18. 「コードをどういう
風に組むか」が
※オレオレ定義

19. 狭義の
App Arch
※オレオレ定義

20. 「どんなテクノロジー
を使うか」も含むのが
※オレオレ定義

21. 広義の
App Arch
※オレオレ定義

23. Domain-Driven
Design

24. Enterprise App
の設計手法

25. 狭義のApp Archも
提案

26. Originally
Proposed by...

29. The essence
was...

30. Customerと
一緒に

31. Domain Model
を考える

32. はいはいワロスワロス
お客さんコードと
か分からんしｗ

33. はい、そうですね

34. でもDDDは

35. App Arch
だけでも
高評価

36. だから
パクろう!!

37. 前提

38. アプリケーション
の性質

39. 中～大規模

40. Win8以外にも
アプリケーション

41. むしろメインは

42. デスクトップ
もしくはWeb

43. 開発要件

45. 柔軟性・変更容易性

46. Ease of
Maintenance
保守性

47. どうやって実現
したら・・・

49. DDD本の副題
Tackling Complexity in
the Heart of software
ソフトウェアの本質である複雑さに立ち向かう

50. DDD brings us ...
DDDがもたらすもの

51. Design Principles

52. オブジェクト
指向設計の
5大原則

53. S ingle Responsibility Principle
O pen Close Principle
L iskov Substitution Principle
I interface Segregation Principle
D ependency Inversion Principle

55. Highly
Cohesive 高凝集

56. Don’t Repeat Yourself
同じコードを2度書くな

57. Keep
the cross-cutting code
abstracted
横断的なコードは抽象化

58. 御託はいい
やれ

59. 全体像

60. ざっくり http://microsoftnlayerapp.codeplex.com/

61. 詳しく http://microsoftnlayerapp.codeplex.com/

62. この辺と
http://microsoftnlayerapp.codeplex.com/

63. この辺と
http://microsoftnlayerapp.codeplex.com/

64. この辺の話を
します
http://microsoftnlayerapp.codeplex.com/

65. ちょっと
その前に

66. Object Types
オブジェクトの種類

67. Entity

68. http://microsoftnlayerapp.codeplex.com/

69. ≒DBレコード

70. でも単なるデータの
容れ物じゃない

71. 例えば
BankAccountクラス
Microsoft.Samples.NLayerApp.Domain.MainBoundedContext.BankingModule.Aggregates.BankAccountAgg名前空間
http://microsoftnlayerapp.codeplex.com/

72. Deposit/Withdraw
メソッド

73. Deposit/Withdraw
の履歴を記録

74. Balanceプロパティ
が常に正しい
状態を保つ

75. 不正な呼び出し
に対しては例外

76. Value Object

77. ないけど
http://microsoftnlayerapp.codeplex.com/

78. プリミティブ
じゃないけど
Entityでもない

79. Stringクラス
みたいな感じ

80. ハッシュコンテナ
のキーとして使える

81. 基本immutable

82. だから
スレッドセーフ

83. 例えば
BankAccountNumber
クラス
Microsoft.Samples.NLayerApp.Domain.MainBoundedContext.BankingModule.Aggregates.BankAccountAgg名前空間
http://microsoftnlayerapp.codeplex.com/

84. Domain Service

85. http://microsoftnlayerapp.codeplex.com/

86. 例えば
BankTransferService
クラス
Microsoft.Samples.NLayerApp.Domain.MainBoundedContext.BankingModule.Services名前空間
http://microsoftnlayerapp.codeplex.com/

87. PerformTransfer
メソッド

88. 2つのBankAccount
間でお金を移す

89. SRP原則のため、
BankAccountには
置くべきでないロジック

90. GoFのデザインパターン
などをよく使うのはここ

91. Template Methodとか
Strategy/Stateとか
よく使う

92. 他にも

93. Repository

94. http://microsoftnlayerapp.codeplex.com/

95. …2箇所？
http://microsoftnlayerapp.codeplex.com/

96. Application
Service

97. http://microsoftnlayerapp.codeplex.com/

98. Domain Service
と違う…?
http://microsoftnlayerapp.codeplex.com/

99. Specification

100. http://microsoftnlayerapp.codeplex.com/

101. Factory

102. ないけど
http://microsoftnlayerapp.codeplex.com/

103. こんな感じで
クラスを小さくして

104. スパゲッティ化
を防いでいく

105. スパゲッティ化
を防いでいく

106. あと

107. Aggregate
集合

108. Highly Cohesive (※)
にするための考え方
※高凝集

109. “Entities” 名前空間に
全部入ってるとか

110. ダメ、絶対

111. さて

112. Distributed
Interface
Layer

113. この辺の話
http://microsoftnlayerapp.codeplex.com/

115. 基本的にDBに
繋げない

116. ざわ‥
基本的にDBに
繋げない

117. ざわ‥
基本的にDBに
繋げない
ざわ‥

118. 解決策

119. はい、そうですね

120. Webサービス

121. 問題は
どのテクノロジを
使うか

122. 1. ASP.NET Web
API (REST)

123. 2. WCF (SOAP)

124. 今時RESTっしょ

125. たしかにそう

126. 流行りは
REST
http://www.infoq.com/jp/news/2011/06/Is-REST-Successful

127. たいてい
RESTでOK
http://www.codeproject.com/Articles/341414/WCF-or-ASP-NET-Web-APIs-My-two-cents-on-the-subjec

129. WCFもなかなか
イケてる

130. クライアント
自動生成
できるから

131. 開発効率
いいし

132. 最近では

133. async/await
にも対応

134. async/await
にも対応
※自動生成クライアントのこと

135. Behaviorで
AOPしたり
http://pablocastilla.wordpress.com/2010/11/09/aop-and-ioc-in-wcf-4-0-with-enterprise-library-5-and-appfabric-part-1/

136. Unity (DIの方) と
組み合わせたり
http://unitywcf.codeplex.com/

137. いろいろできる

138. それゆえに

139. JavaScriptから
呼んだり

140. 他システムから
呼ばれたり

141. 開かれた
サービスには

143. 単に
WinRT用なら

145. 悪くない

146. 死んでない

147. めちゃくちゃ
難しいけど
(・ω<)

148. Configuration
爆発するけど
(・ω<)

149. 補足: WinRTから使えるのは
WCFのサブセット
http://msdn.microsoft.com/library/hh556233.aspx

150. Presentation
Layer

151. この辺の話
http://microsoftnlayerapp.codeplex.com/

152. Win Store App特有なのは
Presentation Layerだけ

153. http://microsoftnlayerapp.codeplex.com/

154. フツーMVVM
でしょ
http://microsoftnlayerapp.codeplex.com/

155. はい、そうですね

156. Presentation
Layerは もしくはMVPVMで
MVVMで!

157. V: View = XAML

158. VM: View Model =
今まで通り
作るだけ

159. Framework使う?

160. MVVM Light
Toolkit?
http://mvvmlight.codeplex.com/

161. Prism 改め
Kona?
http://konaguidance.codeplex.com/

162. Caliburn.Micro?
http://caliburnmicro.codeplex.com/

163. 発展途上なので
何とも言えないが

164. ひとつ言えるとしたら

165. いま使ったらきっと

166. 途中で
アップグレード
したくなるから

167. その辺を
計画しておくべき

168. その辺 (※) を
計画しておくべき
※アップグレードプランとか

169. さてM: Model

170. http://microsoftnlayerapp.codeplex.com/

171. 全
部
M
http://microsoftnlayerapp.codeplex.com/

172. DDD App Archは

173. MVVMから
見たら

174. Mばっかり

175. MにはDomain Logicが
詰まってる

176. まるで宝石箱

177. まるで宝石箱
http://www.officiallyjd.com/archives/14054/201104024_othello_02/

178. Presentation Layer
でも使いたい

179. わざわざ
Webサービス
呼びたくない

180. クライアントのメモリ上で
ロジックを動かしたい

181. Presentation Layerに
コピペすれば?

182. http://www.flickr.com/photos/andrew_freese/2200774154

183. 実現する
方法が

184. あるんだよ!!

185. あるんだよ!!
なっ、なんだってェー！！

186. 1. PCL (Portable
Class Library)

187. 2. コード共有

188. 2. コード共有
プロジェクト間でショートカット張るやつ

189. 以上

190. ( ´ﾟдﾟ｀)ｴｰ

191. そうなんです

192. Windowsランタイム
コンポーネントとか

193. Windowsストア
クラスライブラリは

194. だめ

195. こ
こ
http://microsoftnlayerapp.codeplex.com/

196. .NETで組むから

197. WinRT専用のは
使えない

198. でも

199. おさらい http://microsoftnlayerapp.codeplex.com/

200. http://microsoftnlayerapp.codeplex.com/

201. 矢
印
が
出
て
な
い
http://microsoftnlayerapp.codeplex.com/

202. どういうことか

203. どこにも
依存してない
ということ

204. アセンブリを
分けておけば

205. 他Layerの
アセンブリを
参照しないので

206. Domain Layerは

207. Presentation Layer
からも使えそう!!

208. ここでひとつ
残念なお知らせ

209. 実は・・・ http://microsoftnlayerapp.codeplex.com/

210. ここ! http://microsoftnlayerapp.codeplex.com/

211. たいてい
依存する

212. 例えば
Validation

213. 属性付ける =
依存

214. 依存しちゃ…
ダメ？

215. いいんです

216. Cross-Cutting ... には
依存して当然

217. というわけで

218. Cross-Cutting
Infrastructure
Layers

219. Cross-Cutting
Infrastructure
Layers 長すぎ

221. ロギング

222. 例外処理

223. そういうやつのこと

224. はい、そうですね

225. Enterprise Library
http://entlib.codeplex.com/

226. Microsoft謹製
Cross-cutting
フレームワーク

227. ちょっと
敷居高いけど

228. 使えるやつなんです

229. というわけで

230. 試してみた

231. PCLから
VAB: Validation
Application Block
を使う

232. 結果から言うと

233. 無理でしたorz

234. 今のところ
PCL版はない

235. 次バージョンで
WinRT対応するかも
という話はあるが
http://entlib.codeplex.com/discussions/401661

236. PCL対応の
噂はない

237. 待ってられない

238. 俺がポート
してやる!!

239. ( ｰ`дｰ´)

240. 30分後…

241. (:.;ﾟ;Д;ﾟ;.:)無理

242. ビルドエラーの嵐

243. 理由

244. EntLibの精神

245. Configuration over
Convention
規約より設定 (造語)

246. Win Store Appには
標準のConfiguration
の仕組みがない

247. 相容れない

248. Silverlightでも
状況は同じだが

249. Silverlight版の
EntLibでは

250. XAMLファイルに
Configurationを
保存する仕組みを用意

251. PCL対応するなら
そうなるだろうけど

252. .NETから使う時に
不便になってしまう

253. Configuration以外の
部分のみをPCL化すると

254. 近いクラスなのに
別アセンブリに
入れることに

255. EntLibのPCL対応
への道は険しい

256. 同様の理由で

257. Domain Layerを
PCLで作るのは

258. やめたほうが
良さ気

259. PCLで作るとしたら

260. プロジェクト用の
Cross-cuttingライブラリ
ぐらいかと

261. したがって

262. Presentation Layerで
Mを使うには

263. コード共有
を推奨

264. そしたら
#ifが使えるし

265. まとめ

266. 大事なこと

267. 3つ言いました

269. WCF is NOT
dead!!WCFは死んでねぇ!!

271. 依存関係を
慎重に排除して

272. Keep Domain Logic
Simple and Clean!!
ドメインロジックは簡潔に!!

273. すると

274. Presentation Layer
でも使える

276. EntLib is sleeping...
EntLibはお休み中です…

277. We want EntLib6!!
EntLib6に期待!!

278. そして最後に

283. ありがとうござ
いました!!!

284. Any question?
質疑応答