ドメイン駆動設計の捉え方 20150718

Transcript of "ドメイン駆動設計の捉え方 20150718"

1. 1. ドメイン駆動設計の 捉え方 2015/07/18版
2. 2. アジェンダ • 言葉の定義 • ドメイン駆動設計の原則 • 効果的なモデリングの要素 • 戦略的設計 • より深いドメインモデルへ向かうリファクタリング • しなやかな設計 • ドメインの隔離方法 • まとめ
3. 3. 言葉の定義
4. 4. ドメインとは？ • ドメインとは、ソフトウェアを利用する人達の 活動と関心ごと。 • ソフトウェアの利用は利用者の活動の一部なの で、利用しないシーンも含めて活動の目的・背景 を理解することがドメインを理解するというこ と。
5. 5. モデルとは？ • モデルとは、膨大な知識を整理したシンプルで わかりやすい図。 • 大量のinput情報に対して、本当に重要な情報だ けを選別して、シンプルな表現でoutputするこ と。
6. 6. ドメインモデルとは？ • 対象領域において、プロジェクトメンバの頭の中 で構築された概念の集まり。 • 用語と概念の関係性を表現。
7. 7. ドメイン駆動設計の 原則
8. 8. • ドメインに集中する。 • ドメインモデルを探求する。 • ユビキタス言語を語る。
9. 9. ドメインに集中する • 一番複雑なのは、『ドメインそのもの（ユーザ の活動やビジネス）』 • ドメインの複雑性を考慮して、設計すべき。 • 技術だけに注力して作られたソフトウェアはド メインエキスパートの考え方と結びつかない。 • 業務中心 ＞ 技術中心
10. 10. ドメインモデルを探求する • ドメインに対する深い理解と集中すべき主要な 概念を反映したモデルを作成する。 • ドメインエキスパートと開発者の共同作業でドメ インモデルを作り上げていく。 • ドメインモデルは時間と共に進化する。
11. 11. ユビキタス言語を語る • ユビキタス言語により、ドメインエキスパートと 開発者を結びつける。 • ドメインモデルを作成するための共同作業は、 ドメインエキスパートと開発者で共通認識の言 語を形成していくプロセス。 • ユビキタス言語はコードやタスク・機能の記述 などでも利用
12. 12. 効果的な モデリングの要素
13. 13. ・実装を通して、モデルにフィードバックをかけることが重要 ドメインモデルと実装を結びつける ・モデリングとプログラミングでメンバを分離しない ・モデルの持つ意図を実装に引き継ぐ
14. 14. ・ドメインモデルがプロジェクトの中心で、 他のドキュメントなどはモデルから言葉を取り出す ドメインモデルに基づいて 言語を洗練させる ・最終的には、プロジェクトで流れ続ける情報を 体系化するためのツールとしてモデルを位置付ける
15. 15. ・データモデルと違い、振る舞いと業務ルールも表現する 知識豊富なドメインモデルを作成 ・ドメインエキスパートの頭にある膨大な情報から 役に立つ知識をモデル化する ・開発メンバーが全員参加で作成する ・分析と設計の両方で利用できるモデルを作成
16. 16. ・イテレーションごとに重要な概念を追加し、 不要な概念を削除する ドメインモデルを蒸留させる ・表現すべきことをより簡単に言う方法を見つける
17. 17. ・会話の表現がわかりやすいか、ぎこちないかを検証する ドメインモデルの言葉をブレーンス トーミングなどで実験する ・メンバ全員で一緒にモデルをかみ砕くことにより、 メンバ間のやりとりを変化させていく
18. 18. 戦略的設計
19. 19. • 境界づけられたコンテキスト • 蒸留 • 大規模な構造
20. 20. 境界づけられたコンテキスト • 明示的に境界づけられたコンテキストを定義し た上で、ドメインモデルを適用するのはコンテキ スト内部に限定。 • コンテキスト同士の関係も定義することによっ て、モデルの質が低下するのを避ける。（コン テキストマップのこと）
21. 21. 蒸留 • モデルで最も価値がある領域をコアドメインと いう。 • コアドメインを探す活動を蒸留という。 • コアドメインを見つけて、コアドメインをサポー トする大量のモデルやコードから容易に区別す る手段を提供すること
22. 22. 大規模な構造 • システムをおおよその構造から議論/理解できる ようにするための枠組み。 • 個別部分を最適に構造化するよりも、モデル全 体としての扱いやすさを優先。
23. 23. 大規模な構造 ∼責務のレイヤー∼ • ドメインモデル内にある概念上の依存関係を調 べて、自然な階層が認められたら、階層に抽象 的な責務を割り当てを実施。 • 階層は、ドメインの基本的な現実や優先事項を 伝える。 • 階層の責務を決める際は、技術的な意思決定と いうより、ビジネス上の意思決定で行う。
24. 24. 大規模な構造 ∼責務のレイヤーの例∼ 依 存 関 係 DDD本より引用
25. 25. 蒸留 大規模な構造 依 存 関 係 DDD本より引用
26. 26. 戦略的設計のまとめ • 「大規模な構造」と「蒸留」によって、ドメイ ン内の複雑な関係を理解できるようになる一方 で、全体像を見失わずにいられる。 • 「境界づけられたコンテキスト」によって、別々 のシステムの作業を進めても、モデルを壊してし まったり、意図せず断片化してしまったりする ことがなくなる。
27. 27. より深いドメインモデルへ 向かうリファクタリング
28. 28. リファクタリングのレベル マイクロリファクタリング • コードを読みやすくするなど、技術視点で実 施。 ドメインリファクタリング • ドメインについての新たな洞察から実施。
29. 29. リファクタリングのアプローチ • ドメインリファクタリングから開始。 • ドメインモデルのリファクタリングにおいて、ド メインモデルに対する不満の原因が何であれ、 意図を明確かつ自然に伝達するようモデルを改 良する方法を探し出す。
30. 30. コミュニケーションのぎこちなさ • コミュニケーションのぎこちなさに敏感になる ことによって、リファクタリングの候補を探す。 • ドメインエキスパートと開発者の両方ともドメイ ンモデルにない語彙を使用したら警告サイン。 • 警告サインを好機と捉えて、その語彙を取り込 むことでドメインモデルとコードを改善する。
31. 31. 設計のぎこちなさ • 以下のような複雑な箇所は、ドメイン側の活動 における目的や背景を改めて理解して、改善につ なげる。 • 新しい要求が来るたびに複雑になっていく箇 所 • 説明しにくい複雑な業務ロジックが存在する 箇所
32. 32. リファクタリングの最終目標 • コードが何をしているかを理解できるようにな ることに加えて、コードで表現された背景を理 解できるようになること。 • これにより、ドメインエキスパートとのコミュニ ケーションとコードが関連づき、より深いドメ インモデルを探求できる。
33. 33. 大切なこと • ドメインモデルと実装は、絶えず前進するだけの プロセスではない。 • 初期のドメインモデルと実装では重要と思えな かった問題が、困ったことになるのを防ぐため に、頻繁にリファクタリングを行い、ドメイン モデルと実装を改善するプロセスが大事。
34. 34. しなやかな設計
35. 35. 概要 • 初期リリース以降も、プロジェクトの進行を加 速させるためには、変更に強い設計が必要不可 欠。 • しなやかな設計とは『変更に強い設計』と定 義。
36. 36. テクニックの分類 抽象化 理解を容易にして、 詳細を隠 する 分割 適切な粒度を保ち かつ依存関係を排除する 意図の明白な インターフェース 副作用のない関数 表明 概念の輪郭 独立したクラス 閉じた操作
37. 37. 意図の明白なインターフェース • クラス名/メソッド名は手段ではなく、目的が把 握できるユビキタス言語の名前を付与。 • ユビキタス言語にすることによって、チームメン バーがすぐに意味を推測できる。 • 呼び出し側はインターフェースの内部処理を理解 不要。
38. 38. 副作用のない関数 • 複雑なロジックは、副作用のない関数によって、 安全に実行。 • 副作用とは、システムの状態に対して行われる、 あらゆる変更を意味。 • 呼び出し側で、副作用があるのか/ないのかを安全 に予測できることが重要。 • コマンドクエリ分離の考え方。
39. 39. 表明 • システムの状態を変更するメソッドは、表明に よって特徴づける。 • 表明の具体的な表現方法としては、自動化され たユニットテストで表現。 条件名 説明 事後条件 • 事後条件が操作の副作用なので、メソッドを呼び出すことで保証される 結果を記述 事前条件 • 事前条件とは事後条件が成り立つことを保証するために満たすべき条件 クラスの不変条件 • あらゆる操作が終わったときのオブジェクトの状態を宣言。集約全体の 整合性に関するルールを厳密に定義
40. 40. 概念の輪郭 • ドメインオブジェクトは、意味のある単位をよ り直感的に使用したり、組み合わせたりできる ような単位で分割。 • 最初から理想となる分割はできず、リファクタ リングした結果によるもの。 ✦ リファクタリングは技術視点ではなく、ド メイン視点で実施。
41. 41. 独立したクラス • 関連が多ければ多いほど、モデルは複雑になる ので、オブジェクト間の関連は低結合になるよ うに徹底的にやる。
42. 42. 閉じた操作 • 引数の型と戻り値の型が同じ場合は、閉じた操 作と呼ぶ。 • 閉じた操作にすることによって、引数と戻り値 が同じ型になるので、余計な概念を呼び込む必 要がなくなる。 • 操作の引数や戻り値に新たなクラスが登場する と、新たな依存関係ができてしまう。
43. 43. ドメインの隔離方法
44. 44. 何と隔離する？ • ドメインをシステムの他の機能から切り離すこ とが重要。 • 他の機能とは、画面やデータの永続化の機能の こと。
45. 45. 隔離手段 ∼レイヤ化アーキテクチャ∼ • ドメイン駆動設計では以下４層に分離。 レイヤー名 説明 ユーザインターフェース層 • ユーザに情報を表示して、ユーザからの何らかのリクエストを解釈 アプリケーション層 • ビジネスルールや知識は含まない • やるべき作業を調整するだけで、実際の処理はドメイン層に委譲 • ビジネス状況を反映する状態は保持しない ドメイン層 • ビジネスの概念やビジネスルールを表現 • ビジネス状況を反映する状態はドメイン層で制御され、実際の格納処理 はインフラストラクチャに委譲 インフラストラクチャ層 • ドメインオブジェクトの永続化処理を行う • アプリケーションのためのメッセージ送信
46. 46. 各レイヤの依存関係 • ドメイン層はどの層にも依存させない。 ドメイン層 ユーザインター フェース層 アプリケーショ ン層 インフラストラ クチャ層
47. 47. 隔離する目的 • 本質的なビジネスの知識を捉えることが可能。 • プロジェクトが進むごとに蒸留しやすい設計。 • ソフトウェアの技術（htmlやsqlなど）に関係す る概念と混同しなくなるので、ドメインを見失 うことを避ける。
48. 48. まとめ
49. 49. ドメイン駆動設計の成功 • 深いモデルによって、明確なビジョンがもたらさ れ、そのビジョンが新しい洞察を生み出す。 • しなやかな設計によって継続的な変更が容易に なる。
50. 50. ドメイン駆動設計の成功 • 対象となるドメインを理解し、その理解をソフ トウェアにおいて、具現化することを重視。 • ドメインモデルの品質に満足できないのは、ド メインについて学び続けている証拠。
51. 51. ドメインが存在する限り、 変化し続け 成長し続け 価値を届け続ける ソフトウェアを作り続けることが重要
52. 52. おまけ
53. 53. DDDを理解するために • DDD本には、ドメインモデルとコードを行った り来たりして、深いドメインモデルを築き上げて いく。 • 哲学書のDDD本をちょっとでも理解するために は、本の内容と実践を行ったり来たりして、理 解を深めていくことが重要。 同じような考えで