越境アジャイル勉強会 in 大阪の発表資料。ソフトウェア開発の複雑さ／不確実性に立ち向かうための考え方とやり方。ドメインとドメインロジックに集中する。モデルと実装を一致させる。オブジェクト指向＋エクストリームプログラミング（XP）

1. ドメイン駆動設計
複雑さに立ち向かう
2017年5月20日
越境アジャイル勉強会 in 大阪

2. ソフトウエア開発
複雑さ
不確実性
リスクではなく、チャンス

3. ソフトウェア開発
複雑さと不確実性に立ち向かう
仮説検証型
アジャイル
ﾘﾚｰｼｮﾝｼｯﾌﾟ駆動
要件分析
ドメイン駆動設計
相互補完かつ相乗効果
地図（全体の絵）を手に入れる
・どこの議論をしているのか明らかに
・それが他の部分とどう関係するかを明確に
道なきところに道を見つける
・わかっていないという自覚から出発
・わかっていることを増やす
・短サイクルで反復的に学習する
進化と発展を続けるソフトウェアを生み出す
・中核の課題に集中する
・ドメインとドメインロジックに焦点を合わせる
・重要な要素を選び抜き意図的に組み立てる

4. 相互補完かつ相乗効果
• 仮説検証
• わからないことが前提
• 仮説・検証・学習・実践のサイクル
• そのために全体を俯瞰する(RDRA)
• そのために中核のアイデアをコードを書いて検証する(DDD)
• リレーションシップ駆動要件分析
• 全体像を関係者で共有する
• どこに焦点をあてたか関係者で共有する
• 仮説が有望になれば、横展開をはかる
• 仮説が行き詰まれば、俯瞰してみなおす
• ドメイン駆動設計
• ソフトウェア全体の中核部分に焦点を合わせる
• 見つけた中核の課題に集中して設計を洗練させる
• 中核を洗練させることにより全体に秩序と発展性が波及する

5. ドメイン駆動設計
複雑さ／不確実さと戦いながら
進化と発展を続けるソフトウェアを生み出す
設計の考え方とやり方
ソフトウェアの核心にある複雑さに立ち向かう
根底技法 ２つの設計原則 目指すところ 戦略的取り組み

6. 根底技法
オブジェクト指向
分析設計
エクストリーム
プログラミング
変更容易性／変化への柔軟な対応を重視した技法

7. ドメインロジックの分析設計
（モジュール化）
ドメインモデル
オブジェクトの組み合わせ
演算対象と演算をカプセル化（データとロジック）
コードの重複をなくす
変更の影響範囲を閉じ込める
トランザクション
スクリプト
機能分解／手続き型プログラミング
・Smart UI
・貧血ドメインモデル
・ファットコントローラ
テーブル
モジュール
テーブルに対応するクラスにロジックを集める
・テーブル構造とプログラム構造との密結合
・不自然なロジックの置き場所
・ファットモデル
コードが膨らんできた時に修正や拡張が容易なのはどれか
利用者の関心事や活動の要点をモデル化しやすいのどれか
どこに何が書いてあるか、見つけやすいのはどれか

8. 開発プロセスと分析設計
いつ 誰が 仕様の記述
エクストリーム
プログラミング
毎日分析設計に
投資を続ける
コードを書く人
実行可能なコード
で表現（一元化）
スクラム
スコープの対象外
（どんなやり方でもよい -> やらなくても良い？）
ウォータフォール
アップフロントに
分析し、アップフ
ロントに設計する
・分析者
・設計者
（コードを書か
ない人）
ドキュメントとコー
ドの二重管理
ソフトウェア開発の目的を正しく実現できるのはどのやり方か？
コードが膨らんで複雑になってきた時の修正や拡張がやりやすいのはどのやり方か？

9. ２つの設計原則
ドメインとドメインロジックに
焦点を合わせる
モデルと実装を一致させる

10. プレゼンテーション層
データソース層
アプリケーション層
ドメインロジックに集中する
@Controller
@Service
@Repository
ドメイン
モデル
ここを
インクリメンタルに
成長させながら
左側の開発を駆動する
ドメインロジックを
ここに集約して
オブジェクトで記述する

11. ドメインロジックに焦点を合わせる
• 多くの技術者にとって、なじみがない発想
• 抵抗や反発すらある
• ドメイン駆動設計を指向している技術者でも焦点が
あっていないことが多い
• データの入出力／OR-マッピング
• 機能／ユースケース／ストリーのバックログつぶし
• プログラミング言語仕様と標準ライブラリへの執着
• フレームワークへの執着
• 越境のトレーニング
• 数値、日付、区分に関わるロジックをオブジェクトで表現する
• JUnitで独立して実行（永続化や通信のコードから分離する）
• リファクタリング
• オブジェクト指向エクササイズ

12. モデルと実装を一致させる
• モデル
• さまざまな知識のうち、重要な要素を選び抜き、意図的
に組み立てた簡潔な表現
• 実装
• パッケージ名、クラス名、メソッド名
• メソッドの引数の型、メソッドの型
• 一致させる
• うまく説明できているモデルでも実装した感じに違和感
があれば別のモデルを模索する
• モデルと実装の一致が、ソフトウェアの変更容易性と発
展性のカギになる

13. モデルと実装を一致させる
越境のトレーニング
• 全体像
• ドメイン層のパッケージ図を描く（特に依存関係）
• パッケージ名を使って、ドメインを超えに出して説明してみる
• 中核の関心事
• 中核な関心事を文章にして声に出して読み上げる
• その文章に関連するクラスを抜粋する
• 抜粋したクラスのクラス名とメソッド名で、中核の関心事を声
に出して読み上げてみる
• コードレビュー
• 開発者が、どのようにドメインを理解しているかの表明として
コードを読む
• ドメイン理解の観点からフィードバック

14. 目指すところ
深いモデル
しなやかな設計
次元の違う柔軟性と発展性

15. 深いモデル
• ドメインの根底にある原則や構造の理解（発見）
• モデルの探求としてのリファクタリング活動
• 動いてはいるが、何かぎこちない
• 修正や拡張のたびに、あちこちが破たんする
• 何かを見落としている感じがする
• コードがドメインの説明になっていない

16. しなやなか設計
• オブジェクト指向の設計原則を愚直に丁寧に
• 概念の輪郭と、パッケージ／クラス／メソッドの単位を
一致させる
• 業務の用語とパッケージ名／クラス名／メソッド名を一
致させる
• 宣言的に書けるロジックと、実行時の状態に依存する
ロジックを分離する
• 実行時の状態の不確実性を局所に閉じ込める
• メソッドの引数の型、返す型を自身の型に閉じる
• 言語仕様レベル、標準ライブラリレベルの記述をでき
るだけ隠ぺいする（ラップする）

17. 戦略的に取り組む
長期的に
複数チームで
大規模に

18. 戦略的に取り組む
• 誰が
• 開発現場で、実際にコードを書いている技術者
• その中で視野が広く、経験を積み、他のメンバーへの影響
力がある非公式なリーダー
• どうやって
• 非公式な打ち合わせ／意見交換
• コード一行一行への反映
• テクニック
• コンテキストのマッピング
• コアドメインの蒸留
• 大規模なロジックの構造化
• 時間とともに進化する秩序

19. ドメイン駆動設計
複雑さ／不確実さと戦いながら
進化と発展を続けるソフトウェアを生み出す
設計の考え方とやり方
ソフトウェアの核心にある複雑さに立ち向かう
根底技法 ２つの設計原則 目指すところ 戦略的取り組み

20. ソフトウエア開発
複雑さ
不確実性
リスクではなく、チャンス

21. ソフトウェア開発
複雑さと不確実性に立ち向かう
仮説検証型
アジャイル
ﾘﾚｰｼｮﾝｼｯﾌﾟ駆動
要件分析
ドメイン駆動設計
相互補完かつ相乗効果
地図（全体の絵）を手に入れる
・どこの議論をしているのか明らかに
・それが他の部分とどう関係するかを明確に
道なきところに道を見つける
・わかっていないという自覚から出発
・わかっていることを増やす
・短サイクルで反復的に学習する
進化と発展を続けるソフトウェアを生み出す
・中核の課題に集中する
・ドメインとドメインロジックに焦点を合わせる
・重要な要素を選び抜き意図的に組み立てる

22. 越境のススメ
どんなときも、あなたから始められる
どんなときでも、今日から始められる
どんな状況でも改善できる
正しいと信じる方向に、小さな一歩を踏み出そう、いますぐに…
Transgrade Agile