Upload
atsushi-kambara
View
1.675
Download
0
Embed Size (px)
Citation preview
Application Architecture for EnterpriseWin Store Appswith DDD Pattern
@atsukanrock
Mar, 30, 2013
Room metro Tokyo
@atsukanrockhttp://d.hatena.ne.jp/atsukanrock/
Enterprise Application Architectになりたい DDD Lover
What customers need is...
顧客が求めるもの
Win8=業務システム
http://wp.techtarget.itmedia.co.jp/contents/?cid=12250
すなわち
Enterprise App
Why App Arch?
Team Development
みんなの力をひとつに
はいはいワロスワロス
なるわけないw
はい、そうですね
メンバーが思い思いに開発すると
スパゲッティ
デスマ
防ぐためにあるのが
用語定義※オレオレ定義
「コードをどういう風に組むか」が
※オレオレ定義
狭義のApp Arch
※オレオレ定義
「どんなテクノロジーを使うか」も含むのが
※オレオレ定義
広義のApp Arch
※オレオレ定義
Domain-Driven Design
Enterprise Appの設計手法
狭義のApp Archも提案
Originally Proposed by...
The essence was...
Customerと一緒に
Domain Modelを考える
はいはいワロスワロス
お客さんコードとか分からんしw
はい、そうですね
でもDDDは
App Archだけでも高評価
だからパクろう!!
前提
アプリケーションの性質
中~大規模
Win8以外にもアプリケーション
むしろメインは
デスクトップもしくはWeb
開発要件
柔軟性・変更容易性
Ease ofMaintenance
保守性
どうやって実現したら・・・
Tackling Complexity in the Heart of software
ソフトウェアの本質である複雑さに立ち向かう
DDD本の副題
DDD brings us ...DDDがもたらすもの
Design Principles
オブジェクト指向設計の
5大原則
SOLID
ingle Responsibility Principle
pen Close Principle
iskov Substitution Principle
interface Segregation Principle
ependency Inversion Principle
Highly Cohesive
高凝集
Don’t Repeat Yourself
同じコードを2度書くな
Keepthe cross-cutting codeabstracted
横断的なコードは抽象化
御託はいい
やれ
全体像
http://microsoftnlayerapp.codeplex.com/ざっくり
詳しくhttp://microsoftnlayerapp.codeplex.com/
ちょっとその前に
Object Typesオブジェクトの種類
Entity
http://microsoftnlayerapp.codeplex.com/
≒DBレコード
でも単なるデータの容れ物じゃない
例えばBankAccountクラス
http://microsoftnlayerapp.codeplex.com/
Microsoft.Samples.NLayerApp.Domain.MainBoundedContext.BankingModule.Aggregates.BankAccountAgg名前空間
Deposit/Withdrawメソッド
Deposit/Withdrawの履歴を記録
Balanceプロパティが常に正しい状態を保つ
不正な呼び出しに対しては例外
Value Object
プリミティブじゃないけど
Entityでもない
Stringクラスみたいな感じ
ハッシュコンテナのキーとして使える
基本immutable
だからスレッドセーフ
例えばBankAccountNumber
クラスhttp://microsoftnlayerapp.codeplex.com/
Microsoft.Samples.NLayerApp.Domain.MainBoundedContext.BankingModule.Aggregates.BankAccountAgg名前空間
Domain Service
http://microsoftnlayerapp.codeplex.com/
例えばBankTransferService
クラスhttp://microsoftnlayerapp.codeplex.com/
Microsoft.Samples.NLayerApp.Domain.MainBoundedContext.BankingModule.Services名前空間
PerformTransferメソッド
2つのBankAccount間でお金を移す
SRP原則のため、BankAccountには
置くべきでないロジック
GoFのデザインパターンなどをよく使うのはここ
Template MethodとかStrategy/Stateとかよく使う
他にも
Repository
http://microsoftnlayerapp.codeplex.com/
Application Service
http://microsoftnlayerapp.codeplex.com/
Specification
http://microsoftnlayerapp.codeplex.com/
Factory
こんな感じでクラスを小さくして
スパゲッティ化を防いでいく
スパゲッティ化を防いでいく
あと
Aggregate集合
Highly Cohesive (※)にするための考え方
※高凝集
“Entities” 名前空間に全部入ってるとか
ダメ、絶対
さて
Distributed InterfaceLayer
基本的にDBに繋げない
基本的にDBに繋げない
ざわ‥
基本的にDBに繋げない
ざわ‥
ざわ‥
解決策
はい、そうですね
Webサービス
問題はどのテクノロジを
使うか
1. ASP.NET Web API (REST)
2. WCF (SOAP)
今時RESTっしょ
たしかにそう
流行りはREST
http://www.infoq.com/jp/news/2011/06/Is-REST-Successful
たいていRESTでOK
http://www.codeproject.com/Articles/341414/WCF-or-ASP-NET-Web-APIs-My-two-cents-on-the-subjec
WCFもなかなかイケてる
クライアント自動生成できるから
開発効率いいし
最近では
async/awaitにも対応
async/awaitにも対応※自動生成クライアントのこと
BehaviorでAOPしたり
http://pablocastilla.wordpress.com/2010/11/09/aop-and-ioc-in-wcf-4-0-with-enterprise-library-5-and-appfabric-part-1/
いろいろできる
それゆえに
JavaScriptから呼んだり
他システムから呼ばれたり
開かれたサービスには
単にWinRT用なら
悪くない
死んでない
めちゃくちゃ難しいけど
(・ω<)
Configuration爆発するけど
(・ω<)
補足: WinRTから使えるのはWCFのサブセット
http://msdn.microsoft.com/library/hh556233.aspx
PresentationLayer
Win Store App特有なのはPresentation Layerだけ
http://microsoftnlayerapp.codeplex.com/
はい、そうですね
PresentationLayerはMVVMで!
もしくはMVPVMで
V: View = XAML
VM: View Model =今まで通り作るだけ
Framework使う?
Caliburn.Micro?http://caliburnmicro.codeplex.com/
発展途上なので何とも言えないが
ひとつ言えるとしたら
いま使ったらきっと
途中でアップグレードしたくなるから
その辺を計画しておくべき
その辺 (※) を計画しておくべき
※アップグレードプランとか
さてM: Model
http://microsoftnlayerapp.codeplex.com/
DDD App Archは
MVVMから見たら
Mばっかり
MにはDomain Logicが詰まってる
まるで宝石箱
まるで宝石箱http://www.officiallyjd.com/archives/14054/201104024_othello_02/
Presentation Layerでも使いたい
わざわざWebサービス呼びたくない
クライアントのメモリ上でロジックを動かしたい
Presentation Layerにコピペすれば?
http://www.flickr.com/photos/andrew_freese/2200774154
実現する方法が
あるんだよ!!
あるんだよ!!なっ、なんだってェー!!
1. PCL (Portable Class Library)
2. コード共有
2. コード共有プロジェクト間でショートカット張るやつ
以上
( ´゚д゚`)エー
そうなんです
Windowsランタイムコンポーネントとか
Windowsストアクラスライブラリは
だめ
.NETで組むから
WinRT専用のは使えない
でも
おさらいhttp://microsoftnlayerapp.codeplex.com/
http://microsoftnlayerapp.codeplex.com/
どういうことか
どこにも依存してないということ
アセンブリを分けておけば
他Layerのアセンブリを
参照しないので
Domain Layerは
Presentation Layerからも使えそう!!
ここでひとつ残念なお知らせ
実は・・・http://microsoftnlayerapp.codeplex.com/
ここ!http://microsoftnlayerapp.codeplex.com/
たいてい依存する
例えばValidation
属性付ける = 依存
依存しちゃ…ダメ?
いいんです
Cross-Cutting ... には依存して当然
というわけで
Cross-CuttingInfrastructureLayers
Cross-CuttingInfrastructureLayers 長すぎ
ロギング
例外処理
そういうやつのこと
はい、そうですね
Microsoft謹製Cross-cuttingフレームワーク
ちょっと敷居高いけど
使えるやつなんです
というわけで
試してみた
PCLからVAB: Validation
Application Blockを使う
結果から言うと
無理でしたorz
今のところPCL版はない
次バージョンでWinRT対応するかもという話はあるが
http://entlib.codeplex.com/discussions/401661
PCL対応の噂はない
待ってられない
俺がポートしてやる!!
( ー`дー´)
30分後…
(:.;゚;Д;゚;.:)無理
ビルドエラーの嵐
理由
EntLibの精神
Configuration over Convention
規約より設定 (造語)
Win Store Appには標準のConfigurationの仕組みがない
相容れない
Silverlightでも状況は同じだが
Silverlight版のEntLibでは
XAMLファイルにConfigurationを
保存する仕組みを用意
PCL対応するならそうなるだろうけど
.NETから使う時に不便になってしまう
Configuration以外の部分のみをPCL化すると
近いクラスなのに別アセンブリに入れることに
EntLibのPCL対応への道は険しい
同様の理由で
Domain LayerをPCLで作るのは
やめたほうが良さ気
PCLで作るとしたら
プロジェクト用のCross-cuttingライブラリ
ぐらいかと
したがって
Presentation LayerでMを使うには
コード共有を推奨
そしたら#ifが使えるし
まとめ
大事なこと
3つ言いました
WCF is NOT dead!!
WCFは死んでねぇ!!
依存関係を慎重に排除して
Keep Domain Logic Simple and Clean!!
ドメインロジックは簡潔に!!
すると
Presentation Layerでも使える
EntLib is sleeping...
EntLibはお休み中です…
We want EntLib6!!
EntLib6に期待!!
そして最後に
ありがとうございました!!!
Any question?質疑応答