# DDD本 3章 モデルと実装を結びつける 読書会での便宜のため、各節に勝手に番号を振りました ## もくじ 0. 資料について 1. 前文 2. モデル駆動設計 3. モデリングパラダイムとツールによるサポート 4. 例3.1. - 手続き型からモデル駆動へ 5. 骨格を見せる：なぜモデルがユーザにとって重要なのか？ 6. 実践的モデラ 7. 3章全体のまとめ 8. 作成者による全体のまとめ 9. 議論メモ ## 0. 資料について ### この本のよくないところ * 章立てが粗い * 繰り返しが多く、冗長 * 言い回しが難解な上に同じ言葉が別の意味で用いられる ### 資料作成にあたって意識したこと * 各節の中でも意味ごとに区切る、ただし本文からは離れないようにする * 各節ごとにシンプルなまとめを書く * 難解な言い回しは簡単な言葉に言い換える ## 1. 前文 ### スパゲッティが生まれた2つのケース * ケース1 * 丁寧に設計されたドメインモデルがあったが、複雑過ぎてソフトウェア設計上の指針を全く提供しなかった、という話 * いくら正しく設計されていても、ソフトウェア開発の役に立たないのならば意味がない * ケース2 * 場当たり的に書かれたC++のコードをJavaに置き換える話 * ケース1とケース2は全く別のプロセスを踏んだ成果物なのに、成果物はよく似ていた * 複雑過ぎて保守できない * コードを読んでもシステムの目的がわからない ### モデルの役割 * モデルの役割 * ソフトウェア設計において土台となり、実装に対しても重要な指針を提供する * ドメイン駆動設計では、モデリングにも特別なアプローチが求められる ## 2. モデル駆動設計 ### 分析モデルはよくない * 複雑なプロジェクトは、モデルとコードの間の緊密な結びつきを維持していない * この分離は「分析モデル」を作ることで生まれる * 分析モデルはソフトウェア設計に留意されてないことが多い * ソフトウェア設計はそれはそれで別の抽象化なので、分析モデルと設計のひも付きを維持するのはコスパが悪い * 分析モデルを使うと、ドメインを理解するという目標にすらたどり着けない * 重要な発見は設計・実装の段階で起こる * そのはずなのに、エンジニアが分析は別プロセスだと思うとまともにモデリングがされなくなる * 設計の中心になる部分がドメインモデルに紐付いていないなら、そのモデルにほとんど価値がない * 設計は、コンポーネントの集合を定義しなくてはならない * コンポーネントは、実装できて、実行できて、問題を正しく解決できなくてはならない ### モデル駆動設計 * モデル駆動設計：分析とソフトウェア設計の両方の目的に使える、単一のモデルを探し出すこと * ドメインの抽象化方法とアプリケーションの問題を解決できる設計はいずれも数多いので、両者を結びつける解がある * ほんまかいな * 「確実にそうとは言えないのでは？」という程度の意味 * 結び付けられるからといって、以下を致命的には妥協しないこと * 技術的な配慮 * ソフトウェア設計上の原則を守ること * モデルはドメインの概念を表すこと * この方法を取ることで、設計がモデリングとソフトウェア設計の2ステップになる * 繰り返しが単純になり、イテレーションを回しやすい ### モデルへの要求 * ソフトウェアを設計する際、ドメインと実装の紐付けが明らかになるように、ドメインを設計に忠実に反映できること * 強固なユビキタス言語を支えられること * 設計で使用する用語法（＝ユビキタス言語）と責務の割当を引き出せること * これはつまり、コードとモデルを対応させられるようにしておけということ * 設計でもユビキタス言語を使えということ * オブジェクト指向プログラミングのようなモデリングパラダイムをサポートする、ソフトウェア開発のためのツールと言語 * オブジェクト指向設計とオブジェクト指向言語の対応のようなイメージ ### まとめ モデリングとソフトウェア設計は一体である必要があり、それを解決するのがモデル駆動設計である ## 3. モデリングパラダイムとツールによるサポート * 確認：モデルと設計は対応しなくてはならない * 必要なのは、モデリングの結果と似たものを生成できるソフトウェアツール * オブジェクト指向プログラミングが強力 * モデルを構成する概念に実装を提供する * オブジェクトが実際にメモリ上に存在し、関連を持ち、クラスとして構成され、振る舞いを提供する * Prologもモデル駆動設計と適合する * 集合に属していることと、集合同士の包含関係を表せる * ここで言っている論理とは命題論理のこと ```prolog 人間(ソクラテス). % ソクラテスは人間である 死ぬ(X) :- 人間(X). % 人間であるならば、死ぬ ? - 死ぬ(ソクラテス). % => true ``` * 手続き型は向かない * 構造体などを使っても、データに紐づく振る舞いを定義できない * 関数は概念的なつながりを表さない ### まとめ オブジェクト指向プログラミングと述語論理によるプログラミングがモデル駆動設計に向いている ## 4. 例3.1. - 手続き型からモデル駆動へ プリント基板を使った例で、1.から3.で紹介したモデル駆動設計とツールによるサポートの恩恵を示している 複雑すぎる気がする ### 前提 * プリント基板は、2つのピンをつなぐ導線の集まりとみなせる * この「2つのピンをつなぐ導線1本」のことをネットと呼ぶ * ネットには、それぞれ独自のレイアウトルールがある * ネットには、ひとかたまりにして「バス」という単位を形成するグループがある * しかし、基板のレイアウトツールには、このバスを扱う仕組みがない * あるバスにルールを適用したいとき、同じルールをすべてのネットに適用しないといけないので不便 ### 最初の実装 * ネットに命名規則を設けて、prefixでバスを判別できるようにしておく * バスにルールを適用したいときは、ネットを名前でソートした上でprefixで検索し、順に適用する * ルールが1つなら良いのだが、ルールが増えたり、適用するファイル形式が増えたりするとつらい ### モデル駆動設計を適用した仕様 * 本の中のクラス図の通り * ユニットテストが可能 * 対話式のUIをFacadeパターン（機能を利用する窓口を提供する）で置いてユーザ定義のルールを作ることもできる ### まとめ * 実装に直接つながるようにモデルを構築することで、プログラミングツールの恩恵を受けることができた * つまり、スケールするのが簡単でテスタビリティが高い * ただし、このような設計は一度に現れるものではなく、モデリングとソフトウェア設計の反復による ## 5. 骨格を見せる：なぜモデルがユーザにとって重要なのか？ ### ソフトウェア設計を想像させないユーザへの見せ方の例 * 理論上は、どんな実装だとしても、ユーザへの見せ方は任意に変えることができる * しかし、よくない見せ方というのがあって、ソフトウェア設計を想像させないような見せ方をすると、エンジニアとユーザとで認識に齟齬が生まれる * パフォーマンスやハードウェア制約の都合でどうしても生まれる場合もある * 例）IEのブックマーク * 見せ方：Webサイトの名前とURLの対応を一覧したファイル * ソフトウェア上の設計：URLだけを保持したファイル名の一覧 * Windowsで使えない文字はお気に入りの名前として使えない、という齟齬が起こる ### ユーザへの見せ方はソフトウェア設計に即した素直なものにする * 言及しているのは、本書によくある分析モデルと実装モデルの乖離ではなく、ユーザへの見せ方とソフトウェア設計の乖離 * ユーザへありもしないモデルを見せるくらいだったら、誤解を招くモデルは排除して、実際をそのまま見せるべき * 設計したモデルがユーザとドメインエキスパートの関心事を捉えていれば、設計をユーザに見せても大丈夫 * むしろ、驚き最小の法則を満たしやすくなる ### まとめ ユーザにもソフトウェア設計を見せるようにすることで、結果的に驚き最小の法則を満たせる やむを得ない事情があるならば、それをユーザに見せるべき ## 6. 実践的モデラ * ソフトウェア開発はすべての工程が設計なので、モデラーとエンジニアは一緒に作業すべき * 責任を過剰に分離することはモデル駆動設計の妨げになる ### モデラーとエンジニアが分離された例 * 例）「モデラはモデリングに集中すべき」とされたプロジェクトでは、作ったモデルが使われなかった * 理由1: モデルの持つ意図が引き継ぎの際に失われてしまった * 理由2: 実装や技術からのフィードバックをモデルが得られなかった ### モデラーとエンジニアの分離は悪 * 開発者がモデルに責任を持っていなかったり、モデラが開発から引き離されていたりしたら、実用的なモデルは生まれ得ない * コードを変更するとモデルは変わる * 実装に伴って発生する制約をモデラが習得できず、無理なモデル設計が行われる * また、モデラーのスキルがエンジニアに伝わらないという組織としての問題にも発展する * コードとモデルは一体なので、モデラーはコードに触れなくてはならないし、エンジニアはモデリングを習得しなくてはならない * モデラーでもエンジニアでもない人は、エンジニアを意識して巻き込まなくてはならない * （余談）しかし、大規模プロジェクトにプロジェクトマネージャは不可欠 * 高次の設計（要件定義？）とモデリングを調整 * 第4部で扱っている ### まとめ モデラーとエンジニアは一緒に作業してソフトウェア設計とモデリングが一体になるようにすべき ## 7. 3章全体のまとめ 6の一部のように書かれているが、実質的には次章へのつなぎのパート ### ドメイン駆動設計とは * ドメイン駆動設計は、モデルがアプリケーションの問題を解決できるようにすること * 情報の流れを実用的なモデルに落とし込む * モデル駆動設計は、モデルと実装を結びつける * ユビキタス言語は、コミュニケーションにおいて曖昧さによる誤解が生まれないようにする ### 第2部からの主題 ソフトウェア設計上の意志決定 ## 作成者による全体のまとめ * ドメインの抽象化とソフトウェア設計の両方に使えるモデルを探し出すべし * ドメインの抽象化をソフトウェア設計と一体にすることで、プログラミングツールの恩恵を受けられる * モデルとソフトウェア設計が一体であるように、モデラーとエンジニアは一緒に作業すべき ## 議論メモ * モデラーとエンジニアは一緒の人？ * どちらとも言っていないが、少なくとも同じチームにいる想定 * 同じ人でもOK * ドメインスペシャリスト＝ProductOwner ？ * これは必ずしもそうではない、例えば会計や法律など、専門領域が深い場合 * 専門家がいないような領域（いても社内に必要というほどでもない場合）ならそうかも * 会計ソフトの例だと * ドメインエキスパート＝会計士さん * モデラー＝会計に詳しい人、会計士さんとユビキタス言語を作る人、かつソフトウェア設計に詳しい人で、コードも書ける人 * ユビキタス言語での会話は、プロジェクトに関わるすべての人がそうであるべき * スーパーマンがいればよいが、いなくても熟練者集団くらいは必要そう ## 来週の担当 AQUAさん