IDDD本　第3章 コンテキストマップ
===
###### tags: `IDDD読書会`
## ディスカッション前にお願いしたいこと

- 読んで、各節の概要を書ける方はサマリーを書いて頂けると助かります :bow:
- 読んでの疑問点を、当日までに箇条書きで良いので書き出しておいてください。
- 本の内容を引用するのであれば、 **ページ数** も一緒に書いておいて頂けるとよりスムーズです
- 誰かが書いた疑問について共感する場合は末尾に:+1:をつけてくだい。
- :+1: が多い質問を当日のディスカッションで拾おうと思います

- 疑問点に関する議事録は、文章の頭に//つけています。

## 参加者（ディスカッション参加予定な方、書いておいて頂けるとスムーズです）

| Discord上の名前(呼ばれたい名前) | 簡単な自己紹介（Twitterの紹介ページなどでもOK） | 読書会の参加目的をひとこと |
|:------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------:| --------------------------------------------------------------------------------------------------------------------------- |
| @J.Nakajima(なかじま) | 小売系エンジニアです。最近はチームビルディングやらふりかえり手法を勉強中。普段はbash使い、極稀にPython。<br>Twitter: [@jnuank_](https://twitter.com/jnuank_) | コンテキストマップ面白そうなので、ここはじっくり理解していきたいです |
| @t2_Kobayashi(こばやし) | 自動車部品系企業のIT子会社に所属する、C#ラブなエンジニアです。<br>最近は軽量DDD+CleanArchitecture にチャレンジするも、層の分割に執着しすぎてドメイン貧血症に。 | DDD本もIDDD本も話があっちこっち行ったり来たりしすぎてすぐ迷子になります。なんとか迷わないで済む程度には理解を深めたいです。 |
| @little_hand_s 松岡 | DDD Community Jp主催です、モデリング | |
| @Siena. (しーな/しえな） | フリーランスソフトウェアエンジニア。どちらかというとミドルウェア層辺りが強めかも。モデリングとか好き。 [@n_siena](https://twitter.com/n_siena) | |
| | | |

---

## 3.1 なぜそんなにもコンテキストマップは重要なのか P.84~106

### ■ そもそも『コンテキストマップ』とは？

- DDD に取り掛かる際にまず描くもの。(P.84)
- **プロジェクトの現状** を表したもの。(P.86)
- **シンプルな図で、複数の境界付けられたコンテキスト間の関連** を示す。(P.83)
- より詳細なマップが必要なら **ソースコード** が一番正しく「コンテキスト間の関連をどのように実装しているか」を示している。(P.83)
- ※ 実装の詳細は、主に『13章 境界付けられたコンテキスト』で取り扱う。

---
### ■ 概要

- P.85 CollabOvationチーム(サンプルプロジェクト)は新規開発だったが、コンテキストマップを使うべきだった...プロジェクトについての仮定をマップの形式にしておけば、別の境界づけられたコンテキストについて考えるきっかけとなっただろう。
- コンテキストマップは、解決空間を評価するためで、プロジェクトの現状を表すものを基本は書くが、ゼロベースの場合でも仮定のマップを図示しておけば、早い段階で他のコンテキストを見つけることが出来る

---

- DDD に取り掛かる際には、まずプロジェクトの現状を表すコンテキストマップを描く。(P.84)
- たとえば、大企業で境界付けられたコンテキストの統合(システム同士の連携や利用) を行うとき、
**巨大な泥団子なシステム** との結合を求められるかもしれない。(P.84)
- このときチームは泥団子との間柄が　**顧客/順応者**、新しい良いAPIやいい感じのモデルを提供してくれる あることを期待している。(P.85)
- しかしよくあるのが上流の「泥団子」にそんなつもりがないパターン。
この場合下流のチームは、泥団子の残念なモデルやAPIを押し付けられる **順応者** となってしまう。(P.85)
- 泥団子はだれがどんな風にAPIを使おうと気にしない。
泥団子にとっては、私たちのチームが作ったコンテキストマップも無意味である。
それでも、泥団子との関係性をコンテキストマップにしっかりと反映させる必要がある。(P.84)
- 泥団子のシステムを「境界付けられたコンテキスト」として定義し名前を付け、ユビキタス言語の一部にすること。(P.85)
- 早いうちにコンテキストマップを書いておけば、
依存するほかのプロジェクトとの関係を注意深く考えられるようになる。(P.85)
- ※ コンテキストマップは、チーム間でのやりとりを円滑にするための触媒としても利用できる。(P.85)
- (※ 上流と下流のイメージが(個人的に)逆転しやすいので備忘録としてメモ書き。)
- 上流: 利用する外部のコンテキストのこと。川の上流。図では **"U"** と描かれる。
- 下流: 外部(上流)のコンテキストを使う側のこと。川の下流。図では **"D"** と描かれる。 上流が毒を垂れ流したらさけようがない位置関係。

### 疑問点

### 書記欄

-----
### ■ コンテキストマップを描く(P.86-87)

- コンテキストマップは、将来の姿ではなく **現存する** 地形をとらえるものである。(P.86)
- プロジェクトが進行して風景が変わったら、そのときの状況に合わせて更新すればよい。(P.86)
- コンテキストマップは頑張りすぎないこと。
まずはホワイトボードにマーカーで手書きする程度で十分。(P.86)
- 同じコンテキストに対して、異なる視点で詳細な図を描きたくなるかもしれない。
それがチームにとって価値があるものなら、図でも文章でもなんでもドキュメントにできる。(P.86)
- しかしそれを儀式的な作業(必ず作成するルールを作るなど) にしないこと。
儀式的になるとマップを使いたがる人が減ってしまうし、
あまりにも細かすぎる図はチームの手助けにならない。(P.86-87)
- ↑これはコンテキストマップだけではなく、どんなプラクティスを始めることに対してもありえそう。
- コンテキストマップは、チームのメンバーが常にそれを見て議論できるようにしておく必要がある。(P.87)

### 疑問点

- プロジェクトの現存する地形をマップにする、という風に本章では書かれているが、ゼロベース（新規事業、新サービスなど）の場合は、どうやってコンテキストマップを作るのか
- コンテキストマップと一言に言っても、その詳細さにいくつかレベルがあるように見えます(ACLとか書いたり)。
一般的にはどのくらい真面目に書くものなのか？ :+1::+1:

### 書記欄
- マイクロサービスとして分割するときに分割するときにどうなるか、というレベルでコンテキストマップを作ったことがある。コンテキストの分かれ目がサービスの分かれ目になると思うので、この程度の粒度と思う。
- クラスのモデリングまで行う？
- コンテキストの意味を考えるために必要な程度、ざっくりと登場人物(クラス)を考えた。
- 昔やったけど、いまいちピンとこなかった。詳細に分析することに意味ある？
- 用語を整理する程度にとどめておくのが良いか？
- U と D (上流と下流)を考えておくのは大事と思う。相互依存にならないように整理する。
- 経験: 求人サービスを考えた。ある機能が別のコンテキストじゃないか？と考えて整理していった。データの流れの向きを考えると機能について議論しやすかった。
- Pushとして実装する、Pullとして実装する、ということは考える？
- それは非機能要件なので、コンテキストマップでは考えず、求められる要件に従って実装を変えるのがいいと思う。

----
### ■ プロジェクトと組織的な関係(P.87-P.91)

- サンプルの例(CollabOvation) の、2章終了時点、また本章の終わりでの完成形は超大まかにこんな感じ。(P.87-88)

- コンテキストやチーム間の統合には、下記を利用する。
- **OHS: 公開ホストサービス(Open Host Service)**
- 自身のサブシステムにアクセスできるサービスの集合(API)を、何らかのプロトコル(RESTやRPC、メッセージングなど)で公開する。
- 利用側は公開されたサービスを、プロトコルに従って利用する。
- **PL: 公表された言語(Publish Language)**
- XML や JSON、(現在だと gRPC(.proto) や OpenAPI/Swagger) 、HTML などで作った、コンテキスト間のやりとり専用の、どんなデータをどんな構造で表すかという定義。
(※ どちらかのコンテキストのモデルを共用すると、それに引っ張られてひどい目にあう)
- **ACL: 腐敗防止層(AntiCorruption Layer)**
- 内側にくさったみかん(上流のモデル・PL) を持ち込ませないための層。
層の中で上流のモデル(PL) と自分のモデルを相互に詰め替えることで汚染を食い止めて、上流の影響を極力受けないようにする。

### 疑問点

### 書記欄

----
### ■ 三つのコンテキストのマッピング(P.91-)

- **(※ いきなり話が遡って、コラボレーションコンテキストにセキュリティや権限の情報が混ざっていた 『2.5 サンプルのコンテキスト』の初頭まで戻るので注意。そこから少しずつ上記で示したような状態に戻っていく。)**
- (P.91, 2章 P.70-78 と対応)
- プロジェクトの混乱に気が付いたチームがコンテキストマップを描いてみたところ、どうも図の形が変だ。
コラボレーションコンテキストの中に、セキュリティや権限に関する概念が混じっていることに気が付いた。(P.91, 図3-2)
- このようにサブドメインの分析(問題空間の評価) した結果、
**コラボレーションコアドメイン** と、**セキュリティ汎用サブドメイン** を見つけた。
※ この時点ではまだコンテキストは分離されていない。(P.93, 図3-3)
- この分析結果に従い、隔離されたコア(Evens) を使ったリファクタを行って、
コラボレーションコンテキストから、認証・アクセスコンテキストを分離した。(P.94, 図3-4)
- 次のプロジェクトである ProjectOvation が始まった。(P.95, 2章 P.78-81 と対応)
- まずはコンテキストマップへ **新たなコアドメイン** である **アジャイルプロジェクト管理コンテキスト** を組み込んだ。(P.95, 図3-5)
- 図ではコアドメインなのに「アジャイルプロジェクト管理コンテキスト」の位置が一番下に書かれている。
- 本来、"U" や "D" を付ければ位置関係はどのような形でもよいが、
上流を上、下流を下に配置すると、コンテキスト間の上流/下流の関係性を視覚的に強調できる。
- 川の上流にある街が毒をたれ流したら、下流の街はひどい目にあうというのがイメージしやすい。
- アジャイルプロジェクト管理コンテキストは可能な限り単体で自立して動くようにする。(P.96)
しかし単体で動くと言っても、上流のモデルに一切依存せずにサービスを稼働させるわけではない。DB を丸ごとコピーしてくるわけでもない(依存しすぎる)。

### 疑問点

### 書記欄

----
### ■ コラボレーションコンテキスト(P.98-)

- この時点のコラボレーションコンテキストは、必要になるたびに「認証・アクセスコンテキスト」にアクセスする。
明らかに他のコンテキストに依存していて、自立できていない。 (P.98)
- CollabOvation も、ProjectOvation の時と同じように改善できそうだ。
- 図 3-6 のバウンダリーオブジェクト `UserRoleAdapter` と `HttpClient` でリソースの同期を要求する。
- 要求の結果は、今回は 図 3-7 のように PL で定義された XML の形で返ってくる。
- この XML を、バウンダリーオブジェクトの `CollaboratorTranslator` で、
図 3-7で示したように Moderator 値オブジェクトへマップ(詰め替え) する。
- REST や RPC を使った通信をすると、リモートシステムが使用できない際にローカルの処理が失敗して困る。改善したい。(P.99-100)

### 疑問点

- P.98のバウンダリーオブジェクトとはなんのこと？

### 書記欄
- バウンダリーオブジェクト: 腐敗防止層などにあるもので、他のコンテキストとのやりとりにつかうオブジェクトのことでは。HTTPClient, IdentityAccessNotificationsAdapter, MemberTranslator が該当する。値の詰替えを担当するオブジェクト。

----
### ■ アジャイルプロジェクト管理コンテキスト(P.100)

- 自立性を確保する(上流のシステムが死んでいても動く) ためには、依存するオブジェクトの状態を保持しておけばよい。
- ローカルのドメインオブジェクトを作って、外部のモデルを変換して、**必要最小限の状態**だけを保持する。
- ※ 依存するオブジェクト全体をキャッシュするのは、DDD の一般的な考え方ではない。
- 最初は REST で丸ごと取得する必要があるかもしれないが、
それ以降はリモートシステムからのメッセージによる通知(サービスバス、メッセージキュー、REST など) で十分である。
- ミニマル指向
- リモートの状態の利用に制約を設けることは、ローカル側のモデリングの設計を考えるのにも有効である。
- ローカル側で`ProductOwner`や`TeamMember`というモデルがあったとして、リモート側の`UserOwner`や`UserMember`を反映させたものにはしない。
- これらはリモートの`User`オブジェクトの多くの特性を受け継がせないようにして、不純なものを混ぜないようにする。

### 疑問点

- RESTで必要最低限の状態をドメインオブジェクトを取得したあと、リモート側での変更が生じるたびに、アジャイルプロジェクト管理コンテキストの方へ送る、というイメージ？

### 書記欄

----
### ■ 認証・アクセスコンテキストとの統合(P.100-)

- 図 3-8 の `NotificationResource` には、
「認証・アクセスコンテキスト」で発生した **重要なドメインイベント** を通知する URI が記載されている。
- `NotificationResource`を示すカスタムメディアタイプ（MIMEタイプ）の説明がある。
- ここでは、カレントログとアーカイブされた個別通知ログが取得できる。
- この二種類の通知ログが必要になる理由（フィードベース通知の動作原理について）は、第8章ドメインイベントと第13章「境界づけられたコンテキストの統合」で詳しく説明される
- 参考：[実践DDD本 第13章「境界づけられたコンテキストの統合」～分散システム設計～](https://codezine.jp/article/detail/11178?p=2)
- 図 3-9 のシーケンス図は、
　・「**アジャイルプロジェクト管理コンテキスト**」が**定期的**に、
　・「**認証・アクセスコンテキスト**」における **メンバーの更新(ドメインイベント)** を、
　・ **REST を使った Pull 型のメッセージ通知**で受け取って、
　・**キャッシュ上のメンバーを更新**する。
という一連の処理と流れを示したものである。
大まかには以下のような感じ。
- `MemberSynchronizer` が、タイマーで `MemberService の synchronizeMembers()` を定期的に実行する。
- `MemberService の synchronizeMembers()` では、
「認証・アクセスコンテキスト」からの通知がないかを確認するため
`IdentityAccessNotificationAdapter (とそこから使うHttpClient)` を使って、
認証・アクセスコンテキストが公開する通知チェック用の URI へアクセスする。
- 同 `IdentityAccessNotificationAdapter` は、
上記の URI をたたいた結果(PL) をローカルの `Member` オブジェクトに変換する。
- 最終的に `Member` オブジェクトを受け取った `MemberService` は、
自身の `updateMember()` を実行して、キャッシュ上のメンバーを更新する。
※ 必要最低限の情報だけを持つ `Member` をキャッシュし、
　 自身のドメインで使う `ProductOwner` や `TeamMember` は、
　その `Member` のサブクラスとして定義することで、**依存を最小限に抑えている**。

### 疑問点

- P.101【認証・アクセスコンテキストの統合】の説明の中で、`NotificationResource`ドメインイベントグループが重複して、処理してしまわないようにするのはクライアント側の責務、というのはどういうことか。重複したイベントを発生させないようにするのは、リモート側（認証アクセスコンテキスト）の責務ではないのか？
- 図3-8の`HTTPClient(Facade)`、`IdentityAccessNotificationsAdapter`、`MemberTranslator`はどのコンテキストにも所属しない？
- `MemberTranslator` はリポジトリだと思っておけばよい？

### 書記欄
- メッセージングが実装されてないので、RESTでアクセスする方式なので、重複したものを次々送ってくるという状況が無いからこのような責務の分担にしてるのではないか。
- コンテキストに所属しないのが許される？
- コンテキストの粒度はだいたいアプリの粒度と一致する。アプリのどこかに組み込まないといけないんだけど、実装としてはInfrastructureに入ることになるだろうけど、コンテキストマップのモデリングのときはコンテキストに含めないとしてモデリングするのが適当ということだと思う。
- ACLとして書いておくくらいで済ませておくのがいいのでは。
- OHS/PLは公開しているAPIの仕様のこと(たぶん)。
- MemberTranslatorはJSONをコンテキストの内部のオブジェクトクラスに載せ替えるみたいなことをするクラスのことと思う。
- ACLはリポジトリ層に実装する？
- オニオンでいうと、リポジトリはインタフェイスはドメイン層にあり、実装はインフラストラクチャ層にある。
- 腐敗防止層でドメインオブジェクトを作っている。
- リポジトリの役割の一つは、依存性逆転の導入。DDDではその役割に加えて、集約というものを導入している。
- ドメイン層にリポジトリが有るメリット: リポジトリだけが、集約を表現している。
- メリット2: ドメインサービスからリポジトリを操作するため。

----
### ■ コラボレーションコンテキストとの統合(P.103-)

- **アジャイルプロジェクト管理コンテキスト** と、**コラボレーションコンテキスト** 間のやりとりを考える。
- ProjectOvation が持つアドオン機能では、CollabOvation が提供する機能(フォーラムなど) を利用するため、ProjectOvation だけで自立して動作させるためのハードルは高い。
- 以下、**『プロダクトを作成する』** というユースケースで考える。
- ユースケースは以下の通り。
- アジャイルプロジェクト管理コンテキストで、ユーザーがコラボレーション機能のアドオンを購入済みであるとき…
- ユーザーが、
- プロダクトの情報を入力し、
- チームでのディスカッション機能を ON とし、
- プロダクトの作成を要求すると、
- システムは、
- プロダクトとフォーラム・ディスカッションを作成する。
- 過去、「コラボレーションコンテキスト」が「認証・アクセスコンテキスト」を利用するときは、「認証・アクセスコンテキスト」がすでに内部に持っているユーザーやグループなどの情報を使うだけでよかった。
- しかし今回のユースケースにおいて、プロダクトを作成を要求する時点ではまだ「コラボレーションコンテキスト」の中に、そのプロダクト用の『フォーラムやディスカッションの情報』は存在していない。
- このため、コラボレーションコンテキストが正常に動いていないと、
リモートのリソース(フォーラムやディスカッション) を作成できない。
これが自立性を確保するうえで障害となる可能性がある。
- この課題への対策として、結果整合性を活用するために **ドメインイベント** と **イベント駆動アーキテクチャ** を利用する。(P.104)
- イベント通知は、こちらから通知するだけではなく、相手側からの通知を受け取ることもできる。
- たとえば、「アジャイルプロジェクト管理コンテキスト」が「コラボレーションコンテキスト」へ、フォーラムやディスカッションの作成リクエストを送り、その結果をイベント通知で受け取るといった形だ。
- 外部リソースの作成をその場で待ってしまう(同期処理) と、相手が落ちていると動作しなくなる。
- そこで、相手が処理を完了するまで待たず(非同期処理)、相手側で処理が完了するまでは「処理中」などと表示して放置しておく。
結果をイベント通知として受け取ってから改めて処理するようにすれば、
たとえ相手のシステムが落ちていても、こちらのシステムは自立して動作可能となる。
- 「アジャイルプロジェクト管理コンテキスト」でフォーラムを作成しようとしたとき、リモートの「コラボレーションコンテキスト」が落ちていたとしても、画面に表示されるステータスがずっと『作成中』になっているだけで、システムは動作し続けられる。
- 「コラボレーションコンテキスト」が復帰してフォーラムを作成完了し、
フォーラム作成完了イベントが送られてきたら、その時点で改めてリンクを張るなどの処理をしてフォーラムを利用可能にしてあげればよい。
- 「アジャイルプロジェクト管理コンテキスト」のユーザーが、
**まだ存在しないディスカッションを使用したときなど** はどう取り扱えばいいだろうか？(P.104)
- 考えうるすべてのシナリオをうまく処理するには、使えなくなる場面を明確にすればよい。
- サンプルでは、**標準型** を **ステート** として実装している。
※ Enum で、アドオン無効、未リクエスト、リクエスト済み、利用可能 といったステートを持たせている(P.104-105のコード)
- ステートをうまく活用すれば、準備ができていたらフォーラムに参加可能にするだけではなく、エラーメッセージを表示したり、使えそうで使えない機能を用意して購買意欲をあおることもできる。
- この時点では、まだ「アジャイルプロジェクト管理コンテキスト」でコラボレーション機能をどのように統合するかはっきりしていない。(P.105)
図3-10 にあるバウンダリーオブジェクトも、図に示しはしたが中身はまだ未実装でガワしかない。実装の詳細は、『13章 境界付けられたコンテキストの統合』で扱う。
- P.103【コラボレーションコンテキストとの統合】の【Note：なぜ両方のコンテキストでディスカッションを使うのか】と書かれている
- 両方のコンテキストでの「ディスカッション」は全くの別物である
- コラボレーションコンテキストにおけるディスカッションは集約であり、複数の投稿を管理する
- その投稿自体もまた集約である
- アジャイルプロジェクト管理コンテキストにおける「ディスカッション」は値オブジェクトであり、コラボレーションコンテキストのディスカッションの参照を保持する。
- なお、第13章「境界づけられたコンテキストの統合」で、アジャイルプロジェクト管理コンテキストの「ディスカッション」は全くの別物として扱うべきと、認識が変わる。

### 疑問点

### 書記欄

---

### 疑問点（全体）

- 腐敗防止層は、P97だとドメインサービスもしくはリポジトリの中で実装することが多いといった形で書かれているが、他の実装パターンはありえそうか？

## ■ 3.2 まとめ P.107

### 概要

- コンテキストマップとは何なのか、チームにとってどんなメリットがあるのか、それをどうやって作ればいいのか
- まずはプロジェクトの現状を表す。
- コンテキスト間の関連をどのように実装しているか

---

### 疑問点

### 書記欄
* コンテキストが一つならコンテキストマップは必要ない。コンテキストを分けたくなったときに思い出すくらいで良いと思う。

---

## 輪読会感想ふりかえり用

- Kindleユーザーの方は、本文の文字をそのまま載せるとありがたい。
- 章節番号、図番号、特徴的な表現をできるだけ書く
- こんなお問い合わせが〜みたいな。
- 余裕ある人がテキスト拾う形で。
-

## 読書会進め方ふりかえり用

- 概要書きすぎで質問がバラけすぎてしまう😫 進めにくかったらごめんなさい。
- ↑大体の概要ごとに、疑問点と書記欄を入れてみました。とりあえずこれでやってみましょう。

## その他、メモとか用の領域