「ドメイン駆動設計をはじめよう」という本を読み始めた
まず第一部の「設計の基本方針」についての読書メモをかいていく
設計の基本方針
ドメイン駆動設計（以下、DDD）の方針が整理されている
各章の見出しは以下
- 事業活動を理解する
- 同じ言葉を使う
- 事業活動の複雑さに立ち向かう
- 区切られた文脈同士の連携
1. 事業活動を理解する
事業活動を理解することがDDDで最重要なことであるが、この章では事業活動を理解するために事業活動を分割してとらえる方法を紹介している
以下は分割についてのまとめ
- 事業活動は「業務」という領域に分ける
- 業務領域は、中核・補完・一般 に分類する
- 中核的な業務は他企業では代わりが効かないもので、競合優位性を生み出している業務
- 一般的な業務は、オンライン販売など、どの企業でもやりうる業務
- 補完的な業務は、中核ではないが事業活動に必要不可欠な業務
- 宝飾品メーカーの中核業務が「宝飾デザイン」だとすると「カタログ作成」など
- 補完や一般的な業務は複雑ではないのでアウトソーシングでもいいが、中核的な業務は自分たちでハンドリングできるようにする
この分割方法で考える場合、業務領域の境界（特に中核）はどこなのか？をまず明確にすることが大切であるとわかる
2. 同じ言葉を使う
DDDをやる上では、事業活動を業務領域で分割し、業務の本質を探ることが重要である
業務の本質を探るには業務のエキスパートとの会話が欠かせないが、その時に大事なのが「同じ言葉を使って話すこと」だというのがこの章で書かれていること
確かに従来の開発フローでは、プログラマに渡ってくる設計書に書かれている言葉が、業務のエキスパートが使う（通じる）言葉とは限らない
意識はしているが、どこかで違ってていても気にしない（問題になったら考える）みたいな思考でいることも多いと思われる
あと思うのは、業務のエキスパートが常に言葉の定義を意識して使っているわけではなく、なんとなく使っている場合もある
なので、「それとこれは同じ意味ですか？」と合わせにいく作業が必要になる
どうやって言葉を合わせていくか
会話は業務のエキスパートとだけではなく、ステークホルダー全員だと考えた方が良く、ステークホルダー全員が目を通せるwikiや用語集のようなものは必須である
その他に、業務をモデリングする方法も本では紹介されている
モデリングとは、現実のモノや出来事を簡略した表現にすること
業務の課題を解決するのに必要な情報でモデリングし、業務のエキスパートと共有することで業務の理解を深めることができる
3. 事業活動の複雑さに立ち向かう
使う言葉を合わせていく中で、文脈によっては「用語は同じだがニュアンスが違う言葉」と出会う場合どうしたらいいかがこの章で書かれている
本の例では、販売促進部門が使う「見込み客」と、営業が使う「見込み客」で意味が違う場合を取り上げている
この場合のダメな方法としては以下が考えられる
- 販売促進部門と営業部門の全ての関係を表すモデルを作って相関関係を見ながら会話する
- 巨大で複雑なモデルが出来上がり理解できなくなる可能性がある
- 「販売促進見込み客」と「営業見込み客」のように単語を分ける
- 認知負荷が高くなる、会話にはわざわざ「〇〇の見込み客」とは言わない
良い方法は、おそらくこれは、販売促進と営業を兼務する業務エキスパートがおらず、文脈的に混ざらないことを前提としているが、混ざらないのであれば文脈で分けてしまうのが良い
つまり、事業活動を業務領域で分割するのとは別に、文脈でも分割すると良いということ
どう文脈を区切るか解決したい課題の大小で変わり、設計する時に決定する
4. 区切られた文脈同士の連携
区切られた文脈は混ざらないとはいえ、連携することは必要である
たとえばお互いに影響がある変更をする際など
この章では、この時の連携の仕方が紹介されている
- 緊密な関係なのであれば、変更を双方でちゃんとお知らせする
- モデルを一部共有する
- 依存度が高くなるのでなるべく控えたい
- 利用者と供給者の関係を明確にした上で、どう連携するかを決める
- 利用者が共有者に従属して、一方的に情報を受け取る
- 利用者は供給者の情報を受け取った後、自分たちのモデルに変換する
- 利用者が供給者の情報を取りに行く、その際に供給者は利用者に影響ないようにバージョン違いの情報を取れるようにしておく
- 完全に独立し、同じ機能を重複して作る
