DDD本 14章 モデルの整合性を維持する
===
###### tags: `エヴァンス本読書会`

/poll "アンケート第2問！ >>> この章は難しかった？" "お手上げ" "日本語難しすぎない？" "ちょっと何言ってるか分かんない" "まあ分かる" "余裕でした" "読んでない(小声)" "いま読んでる（小声）"

/poll "アンケート第1問！ >>> 『DDD輪読会への参加は何回目？』" "はじめて！" "2回目！" "3回目！" "100回！" "なんかいっぱい！！！"

# Discord開始位置

- [4/24](https://hackmd.io/-DIDQaqyRt65FMBwFQxaOw?both#%E7%AC%AC4%E9%83%A8-%E5%BA%8F%E7%AB%A0) - [discord](https://discordapp.com/channels/432531367427964929/740202765619429487/835340626186076190)
- [5/6](https://hackmd.io/-DIDQaqyRt65FMBwFQxaOw?both#%E5%85%B1%E6%9C%89%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%EF%BC%88SHARED-KERNEL%EF%BC%89) - [discord](https://discord.com/channels/432531367427964929/740202765619429487/840455270579961856)
- [5/22](https://hackmd.io/-DIDQaqyRt65FMBwFQxaOw#-522%E5%9C%9F%E3%81%AE%E5%88%86%E3%81%AF%E3%81%93%E3%81%93%E3%81%8B%E3%82%89%EF%BC%81-) - [discord](https://discord.com/channels/432531367427964929/740202765619429487/845481189485707284)

# 自己紹介

- なかじま（J.Nakajima）
- ファシリ役
- タイムキーパー役
- こばやし（t2_Kobayashi）
- 読み上げ役

# 参加の仕方

- マイクはいつでもONにして、話に参加して結構です。
- テキストチャットでも、コメントやリアクションでどんどん参加してください！ラジオ担当が拾っていきます。
- 聞いているだけの方もOKです！

# ディスカッションをより豊かにするためのグランドルール

- 参加者は毎回任意
- 今回は不参加、次回は参加をするといった気軽な感じ
- 途中参加も断然OK! まずは聞くだけでも大丈夫です！
- フィードバックを恐れない
- マサカリは怖いと思いますが、アウトプットからのフィードバックを受け、学びを深めていきましょう
- アウトプット7割：インプット3割の気持ちで臨みましょう！
- 経験の有る無しは気にしない
- 自分はDDD非経験者だから……と気後れする必要はないです
- 堂々と意見や疑問を語りましょう
- ページ数と同時に、節のタイトルやキーワードを言って頂けるとスムーズです
- 電子書籍で読んでいるとページ数ではわからないため
- 話していない人が、率先してメモしましょう
- このHackMDはみんなのものです。どんどん書いていきましょう:+1: :+1:
- 気になる質問や同感するものには :+1: を末尾につけてください。

# タイムテーブル

| 時間 | 所要時間 | 内容 |備考 |
| -------- | -------- | -------- | -------- |
| 19:50- | - | 集合開始 | |
| 20:00-20:15 | 15分 | 当日の流れとグランドルールの共有 | |
| 20:15-20:25 | 10分 | 感想記入&HackMDに書かれた皆さんの感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | |
| 20:25-21:55 | 90分 | 本の節ごとにディスカッション（ここでも適宜、HackMDに気づきとか書いていってもらっていいです） | |
|21:55-22:00 | 5分 | 次回開催日と読む範囲決めてクローズ | |

## 下に感想などを書いていって下さい。どんな些細なことでもOKです。

---

# 第4部 序章
## 目安の時間
- 18分

## 感想・気づき

- 第4部では、コンテキスト（14章）、蒸留（15章）、大規模な構造（16章）について説明をしている
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/835478871964123136)
- エヴァンス曰く、コンテキストが根本的であり、一番わかりにくいらしい:+1::+1::+1::+1:
- 下記のような勝手な解釈(;^_^A
- 『言語学におけるコンテクストとは、メッセージ（例えば1つの文）の意味、メッセージとメッセージの関係、言語が発せられた場所や時代の社会環境、言語伝達に関連するあらゆる知覚を意味し、コミュニケーションの場で使用される言葉や表現を定義付ける背景や状況そのものを指す。例えば日本語で会話をする2者が「ママ」について話をしている時に、その2者の立場、関係性、前後の会話によって「ママ」の意味は異なる。2人が兄弟なのであれば自分達の母親についての話であろうし、クラブホステス同士の会話であれば店の女主人のことを指すであろう。このように相対的に定義が異なる言葉の場合は、コミュニケーションをとる2者の間でその関係性、背景や状況に対する認識が共有・同意されていなければ会話が成立しない。このような、コミュニケーションを成立させる共有情報をコンテクストという』
https://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%B3%E3%83%86%E3%82%AF%E3%82%B9%E3%83%88

- > P.337 これらの3つの原則は、別々に使っても役に立つが、一緒に使うと特に強力になり、優れた設計を作り出す上で助けになる。
- 3つの原則が最初何を指すのかわかっていなかったが、コンテキスト、蒸留、大規模な構造のことだと気づいた。

## 疑問

- > P.336 システムにおいて概念的にコアとなる場所、つまり、システムの「ビジョン」をとらえるモデルに集中しなければならないのだ。
- システムのビジョンとは、コアドメインのことだろうか？
- 太字にはなっていないけど、後で出てくるドメインビジョン声明文(P.422)も関係してそう。
- > P.336 境界づけられたコンテキストによって、別々の部分で作業を進めても、モデルを壊してしまったり、意図せず断片化してしまったりすることがなくなる
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/835477742208155708)
- モデルの断片化というのがよくわからない:+1::+1:
- 同じような責務をもつモデルが2つ生まれたりとか、2つ以上組み合わせてはじめて表現ができるモデルとか？
- :memo: 本文中の言葉を使うなら、「重複」と「偽同族語」の発生がその具体例になりそう

---

# 第14章 モデルの整合性を維持する 序章
## 目安の時間
- 18分

## 感想・気づき
- > 各用語の意味が明瞭で矛盾したルールがないという、モデルの内部におけるこうした一貫性は、 `統一性` (unification) と呼ばれる - p.340
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/835483211344773161)
- 用語集に定義あり（なので、Evans独特の表現である可能性がある）
- > モデルの内部的な一貫性。各用語が明快で矛盾するルールがないようにするもの。
- 本文だと「明瞭」で、用語解説だと「明快」。原文だとどちらも `unambiguous` なので、単なる翻訳揺れっぽい（同じ単語には同じ日本語をあててほしかった……）
- 「〜性」なので、「〜するもの」ではなく「〜であること」の方が適切。
- :memo: 「〜性」と訳されているけれど、原語が unification だとすると、「単一化」とかの訳語が当てられそうな気もした(いまさら)
- Oreilly Safari だと、用語集までのリンクが設定されてたりして、親切
- P342 の図14.1のナビゲーションマップの関連性を見つつ読む章なんだと。最初さっと流していたけど、これがこの章の目次だった。
- > P.341 3.特殊な要件を伴うアプリケーションは、その要求を完全には満たしていないモデルを使わなければならないかもしれず、そのせいで、ふるまいをどこか別の場所に入れなければならなくなる
- 巨大なプロジェクトのソフトウェアをすべて単一モデルの下に統一するようなリスクの説明だった。:+1:
- 単一モデルに当てはめようとするといろいろ不整合が生じてしまうから、要求を完全には満たしてないモデルを使わなければいけない、ということかな

- > P.341 本章で提示するのは、モデルの境界や他のモデルとの関係性を認識し、伝達し、選択するためのテクニックである

## 疑問
- > この種の行き過ぎに関して、私に責任があることはわかっている
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/835480577527250955)
- なぜ、ここで急に「私」の話になったのかしら:+1::+1:
- 原文だと `I know I’ve been guilty of this kind of overreaching` で主語が `I` なので、訳の問題でも無さそう
- 「私に責任がある」というよりは「私が悪かった」ぐらいの訳が妥当な気がするけど、ここで急に懺悔しているのはやっぱりピンと来ない:+1:
- どこかでモデルは単一でないといけないって書いてあった気がする。モデルを１つにすることにこだわりすぎたことへの自戒のような気がします。 :+1::+1:
- > 「単一であるべき」→分析〜実装モデルは単一であるべき
ここでの話題 →↑のように作られたモデルが、システム全体で唯一無二のものである必要はない（コンテクスト毎に、そのコンテクストについて統一された分析〜実装モデルを置く）

---

# 境界付けられたコンテキスト（BOUNDED CONTEXT）
## 目安の時間
- 18分

## 感想・気づき

- 細胞のたとえがわかりやすい
- > P.343 明示的な境界は、チーム編成、そのアプリケーションに特有の部分が持つ用途、コードベースやデータベーススキーマなどの物理的な表現などの観点から設定すること。
- 「モデルの一貫性」を大切にしつつ、チーム編成や物理的な観点も含めて…と考え方は理解できるが、規模の大きなプロジェクトだと、粒度がとてもむずかしい
- フラクタルな構造にもしたくなるが、コミュニケーションを考えると、かえって分かりづらくなるため、階層は使わないようにしている
- ここでいう「フラクタル」とはどういう意味で使っているのかしら。
- 適切な表現ではなかったかもしれません。境界づけられたコンテキストの中にも、境界づけられたコンテキストを作りたくなることが…。
- > P.344 しかし、問題は、チームが編成され、人々が交流するそのやり方から始まっているのだ
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/835486101442396160)
- わかりみしかない:+1::+1::+1::+1::+1::+1::+1::+1::+1:
- > P.344 境界付けられたコンテキストは、特定のモデルが適用できる範囲を制限する。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/835486858229710899)
- 5章くらいで出ていたモジュールと似たような感じがしている。モジュールもモデルを抽象度を上げつつ関係性を整理するものだったはず。:+1:
- と思ったら、P.345のコラムに「モジュールは1つのモデルの中で複数の要素を構成するものでもあり、別のコンテキストに対して、必ずしも意図を伝えるものではない」と書いてあった:+1:
- 結局、「モジュール」と「境界付けられたコンテキスト」は何が違う？:+1::+1::+1::+1::+1:
- (モジュールは P.108 を参照)
- > P.346 この例における最も具体的な収穫は、予約モデルチームと運用スケジュールチームの間で、非公式にモデルを共有することのリスクが認識されたということだろう。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/835488063793922098)
- コンテキストマップは理想ではなく、現在のありのままを表現すること、と何度も出てくるとおり、この部分は、筆者がコミュニケーションを重視している現れなんだと感じた:+1::+1::+1::+1:
- モデルの統一性が崩壊する→分派が発生する:+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/835489647223767080)
- 最初の兆候の一つとして言語の混乱が起きる
- 偽同族語（2人の人が同じ用語を使って同じことを話しているつもりだが、まったく違う意味で捉えていること）はとても厄介:+1::+1:
- 料金とか、支払いとか商品とか
- 包括的すぎる名前だと、そういうことが発生しやすいのかもしれない:+1:
- P.346 境界付けられたコンテキストで得られるもの:+1:
- 「コンテキストの内側で作業するチームにとって、得られるものは明確さである」
- 「コンテキストの外側にいるチームが得るのは自由だ」

- 1チーム(3人くらいで)でショッピングサイトのようなシステムを作っている場合は、チームが分かれていないので、そもそも境界づけられたコンテキストは必要なんだろうかと思ってしまう:+1:

## 疑問

- > P.345 境界付けられたコンテキストの中でモジュールが個別の名前空間を作成することにより、実は、偶発的に発生するモデルの断片化が見つけにくくなっているのだ。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/835483963182284811)
- モデルの断片化、という意味がわからない:+1:
- 同じ責務に関するモデル要素が、複数のモジュール (の異なる名前空間) に分割されて作成されてしまうようなことかと。
- :memo: 「同じ責務に〜」ならまさに「重複」の、「解釈の分裂が〜」だと「偽同族語」にあたりそうな
- :memo: 原文の断片化: fragmentation
- :memo: 「モデルの」断片化と言っているので。 一つのモデル要素であるべきものが、分裂してしまうと言うことを問題視していると理解してる。

- 「ありのまま」 is 何
- https://discord.com/channels/432531367427964929/740202765619429487/835488291460481045
- 原文は `this is a look at the project as it is` -> 「ありのまま(as it is)」
- 「だが、最初の一歩は、状況をあるがまま認識することである」というのを踏まえるなら、べき論から入るのではなくまずは現状を把握して、そこにある制約を踏まえた上でマップを考えろよ、ということかしら。
- そこから作られるマップやモデルは、必ずしも「（現状の）あるがまま」になるとは限らないことを含意しているのだとしたら、納得感はある

---

# 継続的な統合（CONTINUOUS INTEGRATION）
## 目安の時間
- 18分

## 感想・気づき

- > P.349 XPの多くのプラクティスは、常に多くの人々によって変更される設計において一貫性を維持するという、この具体的な問題をねらいとしている:+1:
- XPに詳しくないけど、こういう観点で有用性があるって考えたことが無かったな
- 一つ手前の段落でコミュニケーションを推進して、複雑さを減らす方法が必要、と書いてあるので、ペアプロやテストファーストとかその辺りだろうか
- > P.350 すべてのコードと他の実装成果物を頻繁にマージさせるプロセスを策定すること。
- トランクベース開発で小さな変更を1日のうちに何度もmaster(main)にpushしているが、それも一つの施策な気がしている
- 「ユビキタス言語の絶え間ない鍛錬」と何度か出ていて、じゃあその鍛錬ってなんだろう？　と思ったときに、とにかくコミュニケーションを図ることなんだろうと思った。人対人のコミュニケーションの中で用語に何か違和感を覚えたら修正して磨き上げるイメージ:+1::+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/835494661493489734)
- 変な話、相手の言葉すべてを信用せず、ちょっとでも違和感があったら「これってこういうことですか」といった言い換えや、「これってどういう意味ですか？」といった問いかけを躊躇なくできるような関係性や場が無いといけないとも思った:+1::+1::+1:
- 「概念は、別々の頭の中で進化していくからだ」と記載がある通り、ユビキタス言語を常にチームで鍛錬し、概念を統一化していないと、メンバのそれぞれの頭の中で、違った概念が出来がるのだろうなと感じた。だから、コミュニケーションが大事なんだろう。:+1::+1::+1:
- :memo: モデルは進化していくものである、というEvansの主張ともつながる感じ モデルが進化していくなら、その記述に使われるユビキタス言語が進化/変化しない道理は無いですよね、的な
- > ほとんどのアジャイルプロジェクトでは、少なくとも1日に1度、各開発者によるコードの変更をマージしている。
- やれてないのが刺さる．．．

## 疑問

- > P.350 すべてのコードと他の実装成果物を頻繁にマージさせるプロセスを策定すること。その際、分裂に対して素早く警告する自動化されたテストも一緒に用いること
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/835491703149559848)
- 分裂に対して警告を出せるようなテストのイメージが沸かないのですが、これだろうなって思えるものってありますか？:+1::+1::+1::+1:
- :memo: ここでいう「分裂」は、マージされない成果物が発生してしまっていること?
- :memo: 素直に浮かぶ自動テストは専ら「期待した通りの振る舞いか」の検証であって、「知識が分断化していないか」の検出とイコールでは無いのでは。
- :memo: テストケースが重複しだしたとか、テスト粒度にばらつきが出て違和感があるのに気づけるようになるとか？
- 節タイトルのCONTINUOUS INTEGRATIONって、XPの継続的インテグレーションのプラクティスをそのまま持ってきたのだと思っているけど、合っているんだろうか。:+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/835493522018271252)
- 「頻繁にマージして一貫性を保つことにより、分派が見られた時にすぐ発見して修正できるようにすることを意味する。」はいわゆるCIと同じような考え方な気がする。:+1:

---

# コンテキストマップ（CONTEXT MAP）
## 目安の時間
- 18分

## 感想・気づき

- > P.353 状況によっては、チームの仲間で議論するだけで十分かもしれない。
- コンテキストマップという名前にとらわれて図を書かなければ、みたいになりそうだが、それぞれの境界付けられたコンテキストと関係性をチーム内で共有ができることが重要ってことみたい:+1::+1:
- > P.360 2.全員がどこに境界があるかを知っていなければならず、コードのどの一部をとっても、あるいはどんな状況にあっても、そのコンテキストを認識できなければならない。:+1::+1:
- コードレベルで言えば、boundaryとかに置いたり、Infra層に置いたりしておく感じ？
- コンテキストマップの図が、なんか圏論っぽい（圏論にわか勢の感想）
- コンテキスト間の変換が関手っぽい
- （射が不十分な気がするので、コンテキスト = 圏までは言えなさそうだけど……）

## 疑問

- > P.352 境界づけられたコンテキスト間でのコードの再利用は、危険なので避けるべきである。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/835496238320320562)
- 同じアプリケーション内でコンテキストを分割している場合、変換を加えて別モデルとするケースと、そのまま使うケースがあるはず。前者が好ましいのだろうが、工数や期間などから後者の誘惑もありそう。実際の所、どのような基準で使い分けているのか、知りたい。:+1::+1::+1::+1::+1::+1::+1::+1:
- 具体的にはユーザークラスや商品クラスみたいな大きなクラスを使い回すなみたいなことなのかな？
- 元々は同じ処理だとしてもそもそものコンテキストが違えば改修などで進化した後がつらいのかと。

---

# ======= 5/8(土)の分はここから！ =======

# 共有カーネル（SHARED KERNEL）
## 目安の時間
- 18分

## 感想・気づき
- > P.363 結果的に、初めから継続的な統合を行った場合よりも多くの時間を、変換層と修復作業に費やすことになり、この二度手間のせいで共通のユビキタス言語が持つ利点を失うことになる。
- これまでの「継続的な統合」は、1つの境界づけられたコンテキストに閉じた話だと思っていたが、ここでは複数の境界づけられたコンテキスト間での統合を言っているように思える。
- 前者は、1つの境界づけられたコンテキスト内における、モデルと実装の統合。後者は、複数の境界づけられたコンテキスト間の連携をスムーズに行う為の統合？
- 前回の話になってしまうが、最後の一文は、ユビキタス言語は2つの境界づけられたコンテキストに閉じたものでなく、あくまで全体を包括しているものだと表しているように読めた。 :+1:
- > 変更の決定には、他チームとの相談が必要になる。
- 諸々の共有により、時短やユビキタス言語の旨味を活かそうとしているが、書籍「LeanとDevOpsの科学」では、他チームの承認が必要な場合、デリバリーに対して負の効果があるとされていた。どちらを優先するかの判断が難しそう。 :+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/840553820764373022)
- > 目標は、重複を減らして（ただし、境界づけられたコンテキストが1つしかなかった場合のように、重複を取り除くのではない）、2つのサブシステム間の統合を比較的容易にすることである。
- 括弧書き部分を重要に感じた。境界づけられたコンテキストを分けた意味が無くなる。:+1::+1:

## 疑問

- 共有カーネルで管理されるデータの話。複数のコンテキストで共有することに合意されたドメインの情報は、永続化するときにはコンテキストごとに保存するもの(二重管理)だろうか. コンテキスト間で永続化先も共有するのだろうか.:+1: :+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/840550525585981480)
- :memo: 少なくともEvansは、共有カーネルであるなら、その永続先なども共有されることを想定しているように思いますね（それ自体をどう評価するかは別として、少なくともEvansは、という点で）
- :memo: 共有カーネルの話を一回忘れてマイクロサービスで考えた場合、別コンテキストへ変更を連携しますよね。 ということは、ある集約に関するデータを二重管理するケースって、全然あるのかなと思いました。

---

# 顧客/供給者の開発チーム（CUSTOMER/SUPPLIER DEVELOPMENT TEAMS）
## 目安の時間
- 18分

## 感想・気づき
- > モデルを自分たちのために実装し、データを新しい実装向けに変換することは相変わらず必要だが、モデルが同じなら変換は単純にできるはずだ。
- 最初理解に混乱したが、ドメインモデルは共有しつつ、コードは独自に実装するということかな。データは予約アプリケーションから取得して変換するが、概念として見たら同じものとして扱うイメージ（？）
- > 上流チームのメンバが、自分たちの役割は顧客に仕えることだと考えると、非常にうまくいった。
- 上流から下流へのシステム的依存が無いからこそ、下流の意図とは違う形で暴れることができてしまう。だからこそ、ビジネス的に重要な下流（顧客）に、上流側が寄せて行く必要があるのだろう。:+1::+1::+1::+1::+1::+1::+1:
- 上流チームが作成する機能やデータが下流でどのように使われるかを理解していないと、ただ目の前のものを作っているだけで、目的を見失っているのをよく見た。ちょっと違うかもしれないけど、イソップ童話の3人のレンガ職人の話を思い出した。 :+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/840555353421643816)
- :memo: 同じことをしていても、目先をどこに向けるかによってその対象が全く違うもの（レンガの塊、大きな壁、偉大な教会）に見えてくるという寓話で、必ずしも良し悪しを語っていなさそうな印象（原典未読）
- > P.366 したがって、チーム間の関係を形式化すれば誰もがらくになる。このプロセスは、2つのユーザコミュニティの間で要求のバランスを取り、下流で必要な機能に関する作業をスケジューリングするために構成される。エクストリームプログラミングを行っているプロジェクトでは、まさにそのために仕組みが準備されている。それが、イテレーションプランニングプロセスだ。
- 上流チームのプランニングに、下流チームの代表者を参加するということらしい。たしかに顧客と供給者の関係そのまま。
- 以前のプロジェクトで共通機能とアドオン機能開発でチームを分けていたけど、この節で言っている関係そのままだと思った
- 特にアドオン開発機能のほうは特定のエンドユーザが顧客に付いていたので立場が強く、下流チームが変更に対する拒否権を持っている状態だった
- OSSを使って開発するのも、こういう関係なのかもしれない。
- ウォーターフォール的な文脈の上流(工程)・下流(工程)と混同しないよう注意？:+1: :+1:
- 上流(供給者)＝API開発チーム、下流(顧客)＝そのAPIを利用するチーム、のイメージ。
- 下流側から上流側へのお金が流れないと、上流が下流のニーズを満たそうとする動機が生まれづらい。:+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/840556682160373760)
- > リレー競走では、バトンを受ける走者は、常に後ろを見て確認することはできない。
- 喩えとしてわかりやすい。上流、下流だとなんとなく「上流の言うことを聞け」な響きを感じてしまう。タイトルの供給者と顧客、というもわかりやすい。:+1:
- 供給者(Supplier)じゃなくて提供者(Provider)でもよかったりするのかな、と思って英語の単語の意味を調べたら provide は事前に用意したものを提供するけど、supply は足りないものを与える、というところが違うらしく、下流の必要に応じて与えるから supply なのかなと思いました:+1: :+1::+1:

## 疑問

---

# 順応者（CONFORMIST）
## 目安の時間
- 18分

## 感想・気づき
- 上流と下流が同じ目標を共有できているなど、供給者側の動機づけが全くできない場合には、いずかれのパターンが考えられる
- 上流に頼らない方法　→　別々の道
- 上流のモデルが下流にとって歪であると認めた上で、下流にとっての独自のモデルを定義する　→　腐敗防止層
- 設計が歪ではなく、それなりに使えると判断した場合に上流のモデルに順応する　→　順応者
- > P.371 下流チームの要求に合わせたインターフェースは実現する運命にないのだ。
- 外部のAPIとか使うと無条件に順応するしかなく、この考えに入る必要がありそう。:+1::+1::+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/840562897724637185)
- 「顧客/供給者」の関係であっても、供給者側が顧客に対しビジネス的に強く依存していない場合は、いつでも立場が逆転することを踏まえる必要がありそう。判断が付きづらい場合、顧客側も初めから順応者として振る舞っていれば、そこまで損が無い気もするがどうだろう。供給者は供給者で居てもらわないと困るが、あてにはできない。
- > それに対して、設計の品質がそれほど悪くなく、スタイルもそれなりに互換性がある場合は、独立したモデルを完全に断念するのがよいだろう。
- ドメインモデルは境界づけられたコンテキスト毎に作成されるイメージだったが、上流の質が良い場合、下流は上流のモデルを利用することになると言っているように見える。このケースは、共有カーネルのように、モデルに修正を加える際に上流側が気を遣ってくれないはずなので、下流のコンテキストに合った形でモデルが変更されていくとは到底思えない。同じチームでも無い限り、この方法は現実的でないように思える。
- コラムにあるように、下流側のモデルのスコープが上流よりも広ければ、たしかにやり方はあるのかもしれない。
- 自チームのモデルとは若干合わないところがあるにしろ、上流のモデルに順応することによって極力変換のコストが下げることができる。開発がそれによって加速するというのは、フレームワークにも言えそうな感じがしている:+1::+1:
- 特定のフレームワークの思想に順応する
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/840563548047540224)
- > P.372 順応者は共有カーネルと似ていると言える。（中略）この2つのパターンの違いは、意思決定と開発プロセスにある。共有カーネルが、密接に協力し合う2つのチームによる共同作業とすれば、順応者は共同作業に興味がないチームとの統合を扱うのだ
- 共有カーネルは共有するサブセットの統合の頻度やテスト実行に関して言及があったが、確かに順応者に関してはあまり言及されていなかった:+1:
- 順応者側の方が供給者側の変更を検知できるようなテストを書くなど、一方的な感じになりそう:+1:

## 疑問

- 順応者と顧客/供給者の違いがいまいちわからない
- 上流が下流に依存して（下流の都合を考慮して)機能？を供給してくれる（下流が下流の都合でモデルを作れる）関係が理想的な「顧客/供給者」であり、それが難しく、下流が上流に依存する事を選択した場合に「順応者」のパターンになるという理解をしました。依存方向が逆なのかなと。:+1::+1::+1::+1::+1:
- ビジネス的な依存（下流がお金を生む）と、システム的な依存（下流が上流のAPIを叩く）が混同しやすい印象
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/840560099671933008)

- > p.372 コンポーネントとのインターフェースが小さければ、統一されたモデルを共有することはそれほど必須ではなく、変換も選択肢の1つにすぎない
- この文章の「共有は必須ではない」、というのは分かるのですが、じゃあ変換かな？と思ったらそれも選択肢の1つにすぎない、と書かれています。他にどんな選択肢があるんでしょうか。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/840561971437895721)

---

# 腐敗防止層（ANTICORRUPTION LAYER）
## 目安の時間
- 18分

## 感想・気づき

- > P.373 既存のシステムとの統合は、価値のある再利用の一形態である
- 既存のレガシーなシステムとの統合をする時に、なんとなく嫌な気持になることが多いけど、価値のある再利用と言われるとポジティブな気持ちになれそう:+1:
- 逆に言うと、顧客に対して価値を生まないと感じさせる統合については、腹落ちするまで関係者と話さないといけないなと感じる:+1::+1:

- > P.374 腐敗防止層とは他システムへメッセージ送信する仕組みではない。むしろ、あるモデルやプロトコルの持つ概念オブジェクトやアクションを、別のものに変換する仕組みなのだ
- 別のドメインオブジェクトへ変換するためのものであり、プリミティブな値のまま受け渡しするのは腐敗防止層では無いってことだと思っている。:+1::+1::+1:▽

- BFFをフロントエンドの表示に関する関心事に変換するという意味で、一種の腐敗防止層って捉えられそうかなって、ちょっと思った

- 腐敗防止層 = 自分のコンテキストを外から守るための層　という意味合いなので、もうちょっとポジティブな呼び方をした方が良い気がする。名前に引っ張られて、腐敗防止層を挟まれた側に釈然としない気持ちが生まれそう。:+1::+1::+1::+1:

## 疑問

- > P.375 腐敗防止層の持つ公開インターフェースは、通常、サービスの集合として現れるが、まれにエンティティのかたちをとることもある
- 自システム　→　腐敗防止層のサービス　→　他システム　というのはわかるけど、腐敗防止層の中でエンティティを使う時がわからない:+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/840564857761169448)
- > P.377 しかし、ファサードを他のサブシステムと直接統合できるなら、アダプタとファサードの間に通信リンクを置くのが適切な選択肢となる
- この場合、ファサードとアダプタは層がわかれるイメージ？
- ファサードは他サブシステムと同じサーバ（orコンテナ）にデプロイされる？:+1::+1::+1:
- 「通信リンクを置く」っていうのが雰囲気で分かった気にはなるんですが具体的にどういうことなのかよく分かりませんでした:+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/840566188174082058)

---

# 別々の道（SEPARATE WAYS）
## 目安の時間
- 18分

## 感想・気づき

- この節を読んでいると、別々の道を辿るのは若干ネガティブな印象でエヴァンス自身が書いているように感じる:+1:
- 最後の方に書いてあった、結局統合することになった場合の統合が複雑になるかもしれないとは言っている

## 疑問

- P.381「残念なことに、チームは元の習慣に戻ってしまった。再び麻痺してしまったのである。」なぜ・・？別々の道という選択肢がまずかったのか、それとも別々の道を歩めない要因があったからなのか。理由が言及されていない(？)のが気になってもやもやします。:+1:
- コンテキストが結局分けられていなかった？
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/840569868826574889)

---

# ======= 5/22(土)の分はここから！ ========================================================

# 公開ホストサービス（OPEN HOST SERVICE）
## 目安の時間
- 18分

## 感想・気づき

- マイクロサービスでやっていると、自然と別の境界付けられたコンテキスト（≒1つのマイクロサービス）からデータのやり取りをする時にRESTを使っている。そうなるとAPIのPathを叩く方は自然と自身のコンテキストに合う型に変換をしていると思うので、変換サービスを使っていることになっている気がする
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/845625875746783292)
- ここで言っている公開ホストサービスは、返ってくる値そのものがドメインモデルの型を想定している？　だから場合によっては変換サービスを使うのは特殊なケースと言っている？:+1::+1::+1::+1:
- 私もその認識です。他コンテキストのレスポンス内容を自コンテキストの集約に形に落とし込んだりする必要があるので。
- Evansも、ここに限っては概念以上の事はほとんど説明してないので、それほど具体的なイメージもって無さそうな疑惑が
- > 状況によっては、知名度の高い公表された言語を交換可能なモデルとして用いることで、結合度が低くなり、理解が容易になることもある
- RESTにおいてHTTPのフォーマットを援用したり(Content-Typeとか)、iana登録の語彙を使うように推奨したりする話を思い出した:+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/845627453694410762)
- https://www.iana.org/protocols
- 一般に公開された語彙を使うことでセマンティクスを共有する、セマンティクスを共有することでシステム同士がより容易に、最終的には（プロトコルに基づいて判断できる範囲内で）自動接続できるところまで広げられる気がする
- Evansがそのように考えて書いているわけではないと思うが、REST思想との類似点と言えそう

## 疑問
- > P.383 新しい統合の要件に対応する際には、プロトコルに機能を追加し、拡張すること。ただし、あるチームだけに特有の要求は別だ。そのような特殊なケースには、1回限りの変換サービスを使用してプロトコルを拡張し、共有プロトコルは単純で一貫性のある状態に保つこと
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/845623626106535957)
- プロトコルに機能を追加し、拡張すること。　と、1回限りの変換サービスを使用してプロトコルを拡張する、の違いがわかっていない:+1:
- 前者は公開する側の話で、後者は特有の要求を持つチーム側で変換サービスを作るということだろうか
- あるシステム用の内容を、ひとつのプロトコルに含めてしまわないようにする。その場合は、専用のプロトコルを新しく作れ、という読み取り方をしました。
- 特定ケースのために公開I/Fを変更するよりは、専用の変換層を噛ませて公開済みI/Fの方に合わせましょうね、という理解
- 分けてあればよくて、どう分けるかは状況次第でどっちもありえるでしょうね。
- >p385 よりよい方法は、企業が使用しているDB2インタフェースのサブセットを識別し、それをサポートすることだったかもしれない。
- そもそもがDB2ライセンスがないユーザにもソフトウェアを配布できるようにすることが目的だったのに、DB2サポートすることが選択肢に入ってくるの？？

---

# 公開された言語（PUBLISHED LANGUAGE）
## 目安の時間
- 18分

## 感想・気づき

- 一方的にデータを渡す・受け取るような関係性ではなく、相互に情報交換がされることを前提とした関係性と読み取れる
- > そのプロトコルが採用するのはシステム間での交換というドメインのモデルだが、そのモデルは統合されるシステムの内部では使われてすらいないかもしれない。
- 「公開された言語」からはちょっと逸れるが、DDDにおける「ドメイン」が指す範囲を掴む上で重要な言及に見える
- 「システム間での交換」がドメインになりうるのであれば、ドメインは必ずしも「技術的な関心事を排除したもの」ではない、と言えるのでは
- 従って、ドメインを↑のように技術と切り離されたものとして説明したり、「ビジネス知識」という形で言い換えたりするのは、少なくともDDDにおける「ドメイン」という語の説明としては不適切、と言って良さそう
- 用語説明でも、「技術的な関心事」を含めるかどうかについては特に言及していないし。
- > P.384 ドメインモデルは、ユーザのために問題を解決することを目的として開発される。そういうモデルは他のシステムとの通信を不必要に複雑化する機能を含んでいることがある。
- わかる:+1:
- > P.384 複数のアプリケーションのうち、どれか1つの基礎になっているモデルをコミュニケーションの媒体として使用すると、新しい要求を満たすための自由な変更ができなくなる。むしろ、継続している伝達する役割をサポートするため、きわめて安定していなければならなくなるのだ。
- これもわかる:+1:
- 前半の文章と比べると、ソースコードとよく似ている
- 共通化されたコードは依存しているところに影響を与えないよう、安定をさせないといけないといけない:+1:

## 疑問

- >一般的には、各境界づけられたコンテキストにおいて、コンテキストの外にある統合すべき各コンポーネントに向けた変換層を定義することになる。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/845629580319653888)
- 直接関係無い上に今更だが、別コンテキストとの統合について理解できていない。ここで言う統合とは、コンテキスト間で連携する際に生じる差異の解消（変換）を統合と呼んでいる？ 以前出てきた、1コンテキスト内で行う継続的な統合と解釈が混ざってしまい、「なんでコンテキストを分けたのに統合しようとしてるの？」と混乱してしまう。:+1::+1::+1::+1:

# 象のモデルを統一する
## 目安の時間
- 15分

## 感想・気づき

- P.388 図14.10の「最低限の統合」の図が、統合されている感が無いように見える :+1::+1::+1::+1:
- 変換：{壁.位置 <-> 木.場所 <-> 蛇.位置 <-> 縄.ぶら下がる} が統合に当たるのか？
- > P.389 いくらかの想像力をもって議論（おそらく激論）
- 容易に想像ができてしまい、ちょっと面白かった
- 自分で認識できていないものを取り入れるのって、相当難しいですよね…。:+1:
- コンテキストの例えとして、象の話が分かりやす過ぎて感動した:+1:

## 疑問

# モデルコンテキスト戦略を選択する
## 目安の時間
- 21分（ちょっと多め）

## 感想・気づき

- > P.392 サブシステムの中には、開発中のシステムの境界づけられたコンテキストには明らかに入っていないものもある。その例としては、すぐには置き換える予定のないレガシーシステムや、必要となるサービスを提供する外部システムが挙げられるだろう
- いま自分たちの手を加える必要がないもの、という捉え方かな。
- P.393の外部システムとの関係を考えるところは非常に勉強になる:+1:
- モデルを統合する必要がなければ、別々の道
- 統合が必要になれば、順応者か腐敗防止層
- でもあまり順応者を選ぶパターンは無さそうな気がする。スピード重視とか、規模があまり大きくない開発になるだろうか
- もしくは相手のコンテキストの中に身を置くパターン
- P.392の、より大きな境界付けられたコンテキストの話だと思った

## 疑問

- > P.391 実際には、そうした意思決定にはチームより上層の合意が必要となることも多い
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/845636538490814484)
- 自分たちの現状のコンテキストとコンテキスト間の関係性を示すだけなのに、上層の合意が必要になることってあるのか？:+1:
- :memo: 上層が絡むかどうかは開発体制次第なのでどっちでもよくて、原文にあるままで、自チームにおさまらない、ということだけでよいかと。
- > P.391 我々は、実は取り組んでいる主要なコンテキストの一部なのであり、それはコンテキストマップに間違いなく反映しなければならない。我々が先入観というものを認識していて、コンテキストマップが適用できる範囲から外へ出た時のことを忘れなければ、**これは問題ではない**
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/845642150645727252)
- 日本語がよくわからないのだが、コンテキストマップに反映しなくても、コンテキストマップの外の話をちゃんと頭に入れておけば問題じゃないよーって意味なのか？
- > P.392 次に挙げるフォースのサブセットの間でバランスを取ることである。
- ここでの「フォース」とはどういう意味？
- 選択肢的な意味合いじゃないかなと思ってました
- > P.392 別々の境界づけられたコンテキスト間で、機能を深く統合するのは実用的でない。
- 深く統合する、という意味合いをよく理解できてないのですが、どういう意味かわかりますか？
- 変換のインターフェースの数が多くなる、とかそういう意味なのかな
- > p.394 これが意味しているのは、変換層か、場合によっては腐敗防止層を構築するということだ。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/845639643026292739)
- 変換層と腐敗防止層は別？？
- > P.394 チームが大きくなるにつれ、継続的な統合は困難になるのかもしれない
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/845635469526040647)
- 困難の予兆ってどんな感じだろう？　テスト、ビルドに時間が掛かるとか？　モデリング作業が難航するとか？:+1::+1::+1:
- コミュニケーションがうまくいかなくなる
- 同じことを別のものとして話したり、違うものを同じものとして話したり。

# 変換
## 目安の時間
- 18分

## 感想・気づき

- 変換という節を見ていて始めはコンテキスト間の変換の話をしているのかと思っていたが、コンテキスト間の関係性を見直す話のようだった
- ここの話、とても難しく感じる…。:+1:

- ここでの話は、別々の道をたどっていた別々の境界づけられたコンテキストが、共有カーネル→公開ホストサービス→公表された言語を辿るステップを説明しているってことなんだろうか

## 疑問

- > p.400 こうすれば継続的な統合に伴うオーバーヘッドなしに、冗長なものを取り除いたことになる。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/845643186492014593)
- コンテキスト外のモデルをそのまんま使うから、統合に伴うオーバヘッドでないという意味だと捉えたが、その場合でもコンテキスト外のモデル変更に追従しないといけない＝統合必要ではないだろうか？？
- >p.402 6.現実的でないと判明するかもしれないが、レガシーシステムで現在しようされていないモジュールを稼働させることを考えること
- 使用していないモジュールを稼働させる意図がわからなかった。なぜだろう？

---