#サ��ンモデル

[dev-arktks]

わかる！ ドメイン駆動設計 ～もちこちゃんの大冒険～

https://booth.pm/ja/items/392260

第1章 DDDってなに？

p.2 「DDDとは」

> DDD は Domain Driven Design の略で、日本語ではドメイン駆動設計と訳されます。ドメ イン駆動設計はソフトウェア開発手法であり、ソフトウェアモデルを設計する手助けとなる手法です。

p.3 「DDDでは何をする？」

> DDD では 開発者とドメインエキスパートが協力して、ドメインを反映したモデル（ドメイ ンモデル）を作り上げます。

> ドメインとは何か、詳しくは後の章で解説しますが、簡単にいうとソフトウェアを適用す る対象領域です。たとえば会計ソフトを作っているとしたら、そのソフトウェアのドメインは会計業務です。

> ドメインエキスパートとは役職の名前ではありません。今扱っている業務について誰より もよく知っている人、少なくとも自分よりよく知っている人はドメインエキスパートです。次

p.4 「ドメインを反映したモデル」

> ドメインを反映したモデルとは、ドメインを構成する物・概念・振る舞い・関係性を表現したものです。

p.4 「DDDをすべき理由」

> • ドメインエキスパートと開発者を同じ土俵に乗せることで、プログラマーの視点だけで なく業務側の視点も踏まえたソフトウェアを作れるようになる

> • そのソフトウェアに関して理解しているのが一部の人（たいていは開発者）たちだけと いう状況をなくすことができる

> • ドメインエキスパートとソフトウェア開発者、そしてソフトウェアそのものとの間で、一切の通訳が不要になる

> • 設計がコードであり、かつコードが設計でもある

p.5 DDDの要素

> • 戦略的設計 >　　– ユビキタス言語 >　　– 境界づけられたコンテキスト >　　– コンテキストマップ > • 戦術的設計 >　　– エンティティ >　　– 値オブジェクト >　　– サービス >　　– レイヤー化アーキテクチャ

> 戦略的設計をやらずに戦術的設計だけをつまみ��いしても、それは完全な DDD ではありません

第2章 ユビキタス言語ってなに？

p.11 「ユビキタス言語とは」

> ユビキタス言語は DDD を構成する要素のひとつで、DDD の実践には必須です。ユビキタス言語とは、ドメインエキスパートやソフトウェア開発者を含めたチーム全体 で作り上げる共通言語のこと。

> ユビキタス言語は名前集ではありません。ユビキタス言語には振る舞いも含まれます。名 詞だけでなく形容詞や動詞も出てこないとおかしいです。

p.12 「ユビキタス言語を見つけるには」

> • ドメインエキスパートの使っている用語やフレーズを観察する > • 業務のゴール（ユースケースやシナリオと呼んでいることもある）を反映する用語やフレーズを観察する > • 既存のドキュメントを取りまとめて用語やフレーズを見つけ出す

p.13 「変化し続けるユビキタス言語」

> ユビキタス言語を用語集 化しようとドキュメントを作るのは現実的ではありません。ある用語に説明が必要だと思っ たときは、用語集を作るのではなくそれを表すソースコード上のモデルにコメントを書くほうが現実的です

p.13 「ユビキタス言語の適用範囲」

> チームでの会話・ドキュメント・ソースコードなど、あらゆるところでユビキタス言語を利用します。

p.14 「ユビキタス言語の確立」

> • 同じものを表す用語が複数ある > • 概念はあるのに名前がない > • ビジュアルはあるのに名前がない

第3章 ドメインモデル

p.17 「ドメインモデルとは」

> ドメインモデルはドメインを適切に反映したモデルです。コードに落とし込む前の、より概 念的なモデルです。名前や関係性、振る舞いが反映されており、チームメンバー全員が同じも のを思い浮かべ、同じ解釈をするものです。

> • ドメインモデルはドメインを反映したもの > • ソフトウェアモデルはドメインモデルを表現したもの > • コード上のモデル（オブジェクトモデルなど）はソフトウェアモデルを実装したもの

p.21 「ドメインモデル貧血症」

> ドメインモデルと呼んでいるものが実はただの getter/setter しかない値を保持するだけの オブジェクトであったり、ドメインモデル（と呼んでいるもの）を利用する側のコードがほと んどのロジックを抱えているような状態を ドメインモデル貧血症といいます。

第4章 境界づけられたコンテキストって？

p.25 「ドメインとは」

> 組織が行う事業やそれを取り巻く世界のことだ。事業が市場を定義して、プロダクトや サービスを販売する。組織にはそれぞれ、自分たちの対象とする領域についてのノウハ ウや物事の進めかたがある。その領域、そして業務を進めていくための方法が、ドメインだ。

p.26 「サブドメイン」

> ソフトウェアの価値をもたらす部分、ビジネスの問題を解決する部分がコアドメインです

> 支援サブドメインと汎用サブドメインの違いは、業務に不可欠なものかどうかという点で す。いずれも業務をうまく進めるために重要ですが、業務上特別なことをしているのが支援サ ブドメインで、していないのが汎用サブドメインです。

p.28 「境界づけられたコンテキストとは」

> ドメインモデルはユビキタス言語で構成されていますから、ドメインモデルは特定の境界づ けられたコンテキストに属することになります。つまり、境界づけられたコンテキストとは、 ドメインモデルを適用する範囲であるともいえます。

p.32 「食材管理アプリの境界づけられたコンテキスト」

> 境界づけられたコンテキストごとにドメインモデルを作るということは、レシピ検索部分を 別のシステムに入れ替えることになっても、賞味期限管理のドメインモデルは影響を受けない ということです。

第5章 コンテキストマップ

p.37 「コンテキストマップとは」

> コンテキストマップは、複数の境界づけられたコンテキストとそれらの関係性を描いたもの です。これはプロジェクトに関わる全員で共有、理解するためのものです。 > コンテキストマップを作る際に特に気をつけるべきことは、境界づけられたコンテキストの 名前をユビキタス言語の一部にすることです。

第6章 コンテキストマップを活用する

名前 説明 共有カーネル ドメインモデルの一部を共有する 顧客/供給者の開発チーム 2つのチームに顧客と供給者の関係を確立する 順応者 相手のコンテキストに従う 腐敗防止層 隔離するためのレイヤを作成する 別々の道 2つのコンテキストのつながりを持たない 公開ホストサービス 共有プロトコルを公開する 公表された言語 標準化されたプロトコルを利用する 巨大な泥団子 ドメインモデリングを諦め、隔離する