ドメイン駆動設計 思えば遠くにきたもんだ
TRANSCRIPT
「ドメイン駆動設計の実践」
思えば遠くにきたもんだそして、道は続く
ギルドワークス株式会社 増田
2015-09-19（土）DDD（ドメイン駆動設計）実践者の話を聞いてみよう
歩きながら考え、考えながら歩く楽しみながら
時には道に迷いながら
一歩一歩、「そこ」を目指して
「そこ」を目指して歩き続ける
ソフトウエアの核心にある複雑さ
変化に適応しながら成長を続ける
ソフトウェアの変更容易性
ガイドブック
Wabi Sabiを読み解く
生命の現象
「まえがき」 凝集されたメッセージ
• 「ドメイン駆動設計」のふるさと
• 対照的な３つのプロジェクト
• 複雑さという課題
• 設計対開発プロセス
• 本書の構成
• 本書が対象とする読者
• ドメイン駆動チーム
オブジェクトコミュニティ
ドメインモデル
ドメインという複雑さ
ＸＰと設計
目標/土台/主活動/広がり
オブジェクト指向の開発者
最大の収穫を得る方法
「まえがき」を時々読みなおし、そのたびに新たな気づきを得る旅が続いている自分がどこをめざしているか？ どこまで到達できたか？
「そこ」を目指して歩き続ける
ソフトウエアの核心にある複雑さ
変化に適応しながら成長を続ける
ソフトウェアの変更容易性
ソフトウェアの核心にある複雑さ
「まえがき」 複雑さという課題
• もっとも重要な複雑さは、技術的なものではない
• 複雑なのは「ドメイン」そのもの
• つまり「ユーザの活動やビジネス」そのものが複雑
• ソフトウェアにおけるこの複雑な側面を体系的に扱うために
– 一番の焦点はドメインとドメインロジックに合わせる
– 複雑なドメインの設計は「モデル」にもとづかなければならない
ここを理解しはじめた時が転換点挑戦し、手ごたえと挫折を経験しながら、今も挑戦を続けている
活動の目的／背景
ドメインとソフトウェア
利用する人たちの活動と関心事
ソフトウェア
ドメインの「複雑さ」を扱うソフトウェア
ドメインの「複雑さ」を扱うソフトウェア
• 重要な「複雑さ」は、ドメインそのもの
• ドメインの「複雑さ」を「ドメイン層」に集める
– プレゼンテーション層から「複雑さ」を取り除く
– アプリケーション層から「複雑さ」を取り除く
– データソース層から「複雑さ」を取り除く
• 「ドメイン層」に集めた「複雑さ」は、「モデル」を中核にして、見通しをよくし、秩序だてていく
モデル
• 膨大な知識を「要約」したシンプルでわかりやすい説明
• モデリングのスキル＝「要約力」
–重要な要素を発見する力
–本質的でないものを削る力
–厳密に組み立てる力
ドメインモデル• ソフトウェアを利用する人たちの「活動」と
「関心事」の本質を簡潔に表したもの
• 表現
–チームの会話に登場する「言葉」
–ラフスケッチ
–コード
–（文章や図）
コードで表現したドメインモデル
第１部 ドメインモデルを機能させる
第２章言葉を使った意図の伝達
第１章ドメインの知識をかみ砕く
第３章モデルと実装を結びつける
ドメインモデル
ドメインの膨大な情報をかみ砕き、蒸留して重要な関心事を鋭く説明する
選び抜かれたドメインの重要な関心事をコードで表現する
会話を繰り返して「要約」を改善する（重要点を明確にする）
「重要な語彙」をメンバーで合意する／共有する
「モデル」と「実装」を結びつける
「住所」を明示する関連や集約の議論の広がり
関心事の「抽出」クラスの「分割」ではない
関連/集約の設計は不要O-R マッピングが簡単
暗黙の概念「住所」
• もっとも重要な複雑さは、技術的なものではない
• 複雑なのは「ドメイン」そのもの
• つまり、「ユーザの活動やビジネス」そのもの
• ソフトウェアにおけるこの中心的な側面を体系的に扱う
– 一番の焦点はドメインとドメインロジックに合わせる
– 複雑なドメインの設計は「モデル」にもとづかなければならない
ソフトウエアの核心にある複雑さ
ここを理解しはじめた時が転換点挑戦し、手ごたえと挫折を経験しながら、今も挑戦を続けている
変化に適応しながら成長を続ける
ソフトウェアの核心にある複雑さに立ち向かうために
「適応型」のソフトウェア開発開発のスタイル
方法論ソフトウェアの最終形（着地点）
開発サイクル
予測型ウォータフォール
事前に定義厳密に定義
固定分析/設計/製造
反復・漸進型
RUPそれなりに定義
反復ごとに精緻化
方向付/推敲/作成/移行
各フェーズで分析/設計/製造を、N回「反復」する
適応型XP
スクラムざっくりと定義
日々更新日、週、春夏秋冬
（人間の生活リズム）
ここの発想の転換が大きな突破口体にしみついたウォータフォールスタイルとの戦い
ソフトウェアの開発スタイル• 「変更」との戦い方の歴史
– 変更のコストとの戦い方
– 変更のリスクとの戦い方
• 「エクストリームプログラミング」は、積極的に「変化を目指す」開発スタイル
変更を管理する
変更を受入れる
変化を目指す
予測型 反復・漸進型適応型
（創発型）
転換点• ずっと疑問だったこと
– アジャイルでの「設計」のやり方 （やらない？）
• 気づき– ＸＰは設計に関するセンスを持った開発者にもっとも
適している by エリック・エヴァンス– 毎日、設計に投資する by ケント・ベック– オブジェクト指向では、分析/設計/実装/保守は「シー
ムレス」である by バートランド・メイヤー
• 行動– オブジェクト指向の「変更容易性」の勉強のしなおし– 現場での体験と手ごたえ– エクストリームプログラミングの再発見
変化を目指す開発チーム• コミュニケーション
– 言葉を使って意図を伝える
• シンプリシティ– 複雑になるほど変化が難しくなることを知っている
• フィードバック– 経験／実験にもとづき進むべき道を探す
• 勇気– 行動する勇気、耐える勇気
• リスペクト– お互いの考えと行動に関心を持ち、かつ、尊重する
• ソフトウェア（の設計）
– ドメインモデル
– ドメイン層
– アプリケーション
• ヒト
– 開発チーム
– 個人
変化に適応しながら成長を続ける
ソフトウェアの核心にある複雑さに立ち向かうための開発スタイルドメインモデルを少しずつ成長させていくドメインモデルの成長は、チームの成長 （要求理解度や設計スキル）ドメインモデルとチームの成長がソフトウェア全体に波及しくいく
ソフトウェアの変更容易性
ソフトウェアの核心にある複雑さに立ち向かうために変化に適応しながら成長を続けるために
オブジェクト指向と「変更容易性」
• 抽象データ型／段階的抽象化
– プログラムを人間の発想に近づけると扱いやすい
• モジュラープログラミング
– 独立性の高い部品に分けると扱いやすい
• メッセージング
– 部品の組合せ方を柔軟にすると扱いやすい
どのパラダイムにも共通する設計の考え方ドメイン層のコードは、たぶん似たものになる
LocalDate
日付を汎用的に扱う手段Java APIのレイヤ
int yearshort monthshort day
LocalDateの内部Java言語仕様のレイヤ
if( day > 31 ) …
DateOfBirth
「誕生日」に用途を限定した独自定義クラス「ドメイン層」の一級市民（ドメインオブジェクト）人間の発想
コンピュータの仕組み
抽象データ型／段階的な抽象化コードを人間の発想に近づける
Boolean 今月が誕生月()Days 誕生日まであと何日()
plusDays()plusMonths()
「モジュール化」と「メッセージング」
受付役
仲介役
回答役
経路情報専門家
判定役
おーい手伝って
後はまかせた
おーい考えて
おーい教えて
教えて
最短経路は…
独立性の高い部品
独立性の高い部品
独立性の高い部品
独立性の高い部品
独立性の高い部品
人間の営みと同じ仕組み必要に応じて最適チームを結成
オブジェクト指向への道
• よくわかっていなかった– 本を読んでもわからない– コード書いてもぴんとこない– 冗長で遅いだけ？
• 1990 頃 Unix/C• 1995 頃 DOA＋手続き型プログラミング
– Oracle, PL/SQL, Pro*C
• 1998 頃– Java, DTO, 長いメソッド,大きなクラス
• 2005年12月30日 運命の電話
転換点
• 変更に苦しんだ大炎上プロジェクト (C#)– どこに何が書いてあるかわからない– 変更した時に、どこで何がおきるかわからない– 同じ修正をあちこちに適用
• 修正漏れ• 不要な箇所のまちがった修正
• リファクタリング– 面白いように効果がでてくる– メソッドの抽出– クラスの抽出– プレゼンテーションとドメインの分離– 手続き型からオブジェクト指向へ
手続き型からオブジェクト指向へ• 値オブジェクト
– データとロジックを一箇所にまとめる– 状態を変えない／自分と同じ型のオブジェクトを返す– 「型名」を使った意図の伝達
• インスタンス変数の「型名」• 引数の「型名」• メソッドの返す「型名」
• ファーストクラスコレクション– インスタンス変数にコレクションを持つオブジェクト– コレクションの操作の置き場所– 可変性の閉じ込め方
• メソッドオブジェクトによるメソッドの置き換え– 長いメソッド／複雑なローカル変数の使い方
• 「データクラス」へ「ロジック」を移動
変更が楽に安全になる手ごたえ
その次にきた転換点
• 基本構造は「トランザクションスクリプト」だった– アクション駆動（ユースケース駆動）– DTOとコードの重複– プレゼンテーション層へのドメインロジックの分散
• ドメインモデルパターンへ– ドメインオブジェクト
• 分析クラスをそのまま実装クラスに
– ドメイン層• ドメインオブジェクトのネットワーク
– 機能駆動／画面駆動／テーブル駆動ではない設計スタイルへ
ドメインモデルパターンへ
• 「重複が減る」– by マーチン・ファウラー
– 飛びついた
– やってみたら、ほんとうに重複が減った
• 「ドメイン層」の開発に集中せよ– Spring それ以外の層は俺たちが良いものを提供
するぜ by ロッド・ジョンソン
– ソフトウェアの複雑さの核心は「ドメイン」そのものby エリック・エヴァンス
ドメインの「複雑さ」を扱うソフトウェア
他の層からドメインオブジェクトを使う
• プレゼンテーション層– Thymeleaf
• ピュアな HTML とドメインオブジェクトのマッピング技術
• アプリケーション層– @Service
• 「やりたいこと」の宣言のみ
• 具体的な判断・加工・計算はドメインオブジェクトまかせ
• データソース層– MyBatis
• ピュアな SQL とドメインオブジェクトのマッピング技術
• ドメインオブジェクト
• 独立性の高い部品
• 柔軟な組み合わせ
ソフトウェアの変更容易性
実戦的な練習 考え方の勉強
Spring BootThymeleafMyBatisJava 8
実装技術
しなやかな設計ドメインモデルの進化を加速
まとめ
「そこ」を目指して歩き続ける
ソフトウエアの核心にある複雑さ
変化に適応しながら成長を続ける
ソフトウェアの変更容易性
一歩一歩、「そこ」を目指して
歩きながら考え、考えながら歩く楽しみながら
時には道に迷いながら