コードに語らせるために
#JJUG_DDD
グロースエクスパートナーズ(株)
ITアーキテクト 和智 右桂
JJUG DDD 2014
和智 右桂
JavaEE勉強会 所属
グロースエクスパートナーズ株式会社 勤務
Yukei Wachi
@digitalsoul0124
Digital Romanticism
http://d.hatena.ne.jp/digitalsoul
ネコ好き
Photo by @digitalsoul0124 All rights reserved.
IT アーキテクト
時々翻訳をしています
Coming
Soon !
•DDDとは
•開発の中のDDD
•手続きからモデル駆動へ
•まとめ
アジェンダ
Photo by @digitalsoul0124 All rights reserved.
スライド中で使用されている画像について、
その著作権の全部または一部は、 クレジットに示した著者によって保留されています。
DDDとは
Domain
Driven
Design
Eric Evans http://www.flickr.com/photos/chrstopher/1447594745/ by Chrstopher
Eric Evans
出版は2003年
• 2001年 Windows XP
• 2002年 J2SE 1.4 リリース
• 2003年 Spring Framework リリース
• 2004年 Oracle 10g リリース
• 2005年 StrutsがApacheトップレベル
プロジェクトに昇格
Chronology http://www.flickr.com/photos/elsie/4607687530/ by Elsie esq.
DDDの主な参考文献
エッセンスは?
ソフトウェア開発とは、
学習と再構築の過程
顧客の業務を理解すること
顧客の言葉で理解すること
Ubiquit!s Langua"
モデルを共有すること
hands wikipedia aussiegall http://www.flickr.com/photos/nojhan/3204073130/ by nojhan
Model
Astrolabe http://www.flickr.com/photos/biker_jun/4450890981/ by Biker Jun (Offseason mode!)
モデルを基に
Model D#ven
Design
ソフトウェアを作ること
DDDの二本柱
ユビキタス言語
•チーム内のすべてのコミュニ
ケーションとコードにおい
て、その言語を厳格に用いる
•図やドキュメント、会話の中
で同一の言語を用いること
モデル駆動設計
•ソフトウェアを設計する際に
は、ドメインモデルを文字通
りの意味で忠実に反映させる
こと
モデリングパラダイム
•モデルとコードを結びつける
ツール
two businessmen shaking hands http://www.flickr.com/photos/mytudut/5188623575/ by MyTudut
nutshell
レイヤ型
アーキテクチャ
ドメインレイヤとは、
ドメインモデルが息づく場所
DSC_0082 http://www.flickr.com/photos/artgoeshere/2338940084/ by artgoeshere
Layered
Architecture
ドメインモデルの構成要素
エンティティ
サービス
バリューオブジェクト
リポジトリ
Bright Blocks http://www.flickr.com/photos/venosdale/4323751812/ by KTVee
Entity
Value Object
Service
Repository
ファクトリ
Factory
Aggregate
集約
モジュールModule
イテレーティブなプロセス
コミュニケーションを通じて
モデルは深みを増していく
"S'il te plaît, fais moi un dessin..." http://www.flickr.com/photos/locktofob/4212943811/ by Locktofob
deep model
戦略的設計
文脈
抽出
大局的構造
システムが巨大化しても
モデルは実装と結びついていなければならない
ISS http://www.flickr.com/photos/wildopallei/2087950431/ by Opal Lei
Context
D&tillation
lar"-scale (ructureStrategic Design
そう言われましても
開発の中のDDD
•機能の階層に分解する
‣のっぺりとした対象に境界線を
引いていく作業
• いくつか流儀はあるが、DDDで
特別なことはない
システム分析
広告 注文 請求
広告を
作る
広告を
参照する
注文する
請求書を
作る
請求書を
送る
Alister Cockburn Writing Effective Use Cases Addison-Wesley 2001 p.62
ユースケース分析
• 業務フローを元にユースケースを
分析
構成図と個別の設計
•機能間の関連の分析および機能ご
との設計
アーキテクトの場合...
• 領域の特性を見極めた適切な
 境界設計とインターフェイス設計
• 全体的なデータモデリング
プログラマの場合...
• 領域内での適切なモデリングと
 プログラミング
私、保守なんですけど
DDDの本質は成長
そういえばこんな本も
#ステマ
テストに導かれて
オブジェクト指向
ソフトウェアを
育てる
ドメインモデルのための余地
手続きからモデル駆動へ
複雑な 業務
•あらゆる機能で必要というわけで
はない
‣単純な業務=データスキーマの操
作だけで表現できる業務なら手
続きで十分
•技術面での難易度とは別
エンティティの先
• モデルによってとらえられる知識
は「名詞を見つける」ことに留ま
らない。ビジネスの活動やルール
もドメインにとって中心的
• エンティティを超えてその先に行
こうとする動きに伴った時こそ、
知識のかみ砕きは力を発揮できる
たとえば...
•機能をまたいで繰り返し現れるif文
をエンティティへの問い合わせに
if (FUGA.equals(someEntity.getHogeFlag)) {
// do something very important
}
if (someEntity.isInSomeState()) {
// do something very important
}
画面A 処理A
画面B 処理B
画面C 処理C
ドメインロジック
レイヤ化アーキテクチャ重要
ドメインレイヤ
画面A 処理A
画面B 処理B
画面C 処理C
ドメインロジック
ドキュメントも、テストも
ユーザーが理解できないモデル
を作ってはいけない
それは、
モデルではない
躓きこそ最大のチャンス
まとめ
•顧客の業務を顧客の言葉で理解
し、モデルとして再構成する
•事前の適切なアーキテクチャリン
グと、フィードバックを受け取り
ながらの成長
•躓きこそが最大のチャンス
•読んでいない方は、第一部だけで
も読みましょう。
ありがとうございました!
Photo by @digitalsoul0124 All rights reserved.

コードに語らせるために