Bounded Context
参考
>#WIP
マイクロサービスの文脈
大きめのプロダクトを複数チームで作る際に、
プロダクト全体のユビキタス言語を統一したり、するのではなく、
境界を明確に引き、その中で統一性を保とう、という感じかな
プロダクト全体で統一使用することは現実的ではないし、コストにも見合わない
そこで、文脈によってモデルを切り分ける
これのことをBounded Context呼ぶ
一つ一つのモデルが、Bounded Contextの中で完璧に論理的に統一されていることが重要
例えば、ステークホルダーごとに異なる概念であるような「決済」について、
複数チームが無理に同じclassで実装しようとして悲惨な目に合った的な話が
p.339-340に書いてる
でかいプロダクトの方がイメージしやすい
例えば服の会社内で、
商品 という用語1つとっても、服を作る人からすれば、売値とか在庫数が関心事だが、
配送を管理する人からすれば、配送先や配送状況が関心事になる
これを一緒くたに扱うのではなく、別の文脈です、と区別する
最初から読んでないので、ここで言う「モデル」が何を指しているのか曖昧 #??
EntityやRepositoryなどの集合のことを1つのモデルとよんでいるのか？
大きいプロダクトかどうかはあまり関係なさそう？
まず前提の問題として、
人間間は別のものだと捉えているものを
同じ実装で表現している
というズレが問題
人間間というのは、少人数チームの2人かもしれないし、
別のチームのことかもしれない
まずここがズレていたらだめ
その上で、指している対象は同じっぽいが、微妙に違う、という時に
もう別物として作っちゃう、という判断も必要になる
一緒にできるなら一緒にしても良い
とにかく、別物として作ったものは、明確に別物だよ、というのが伝わる状態でないといけない
別物のモデルを同じものだと捉えることで問題が起きる
協会を作ってスコープを絞る
その外のことは忘却する
ただし、内部では完全に一貫したモデルを共有する
どうやって境界を作るか？
>明示的な境界は、チーム編 成、そのアプリケーションに特有の部分が持つ用途、コードベースやデータベーススキー マなどの物理的な表現などの観点から設定すること。
まあそうなりそうだよね
同じコードベースでルールで境界付けるの運用でカバーなので辛そうだし
逆に言えば、同じチーム内では同じモデルを扱うようにしましょうとも言える
モデル(?)レベルの話で言えば確かにbounded contextみたいなのは必要というのはわかる
ただ、これってもっとミクロのmoduleの話でも同じでは
module内で複数の同一モデルが出現することはそうそうないだろうけど、
moduleはmoduleの役割を果たせば良いだけで、外部のことはどうでも良い、という意味では同じ
と思ったら違うと書いてた
>しかし、モジュールは1つのモデルの中で複数の要素を構成するものでもあり、
>別のコンテキストに対して、 必ずしも意図を伝えるものではない。
これはまあわかる
>境界づけられたコンテキストの中でモジュールが個別の名前空間を作 成することにより、
>実は、偶発的に発生するモデルの断片化が見つけにくくなっているのだ。
bounded contextは「同じ文脈内に、同じようなものがないぞ」という主張に力点が置かれているということだろうか？
context同士はeventでやりとりをする
ただ、それがqueueなのかDBを経由するのかは後で考えれば良い
Bounded Contextに入る直前にvalidationをかける
Contextの中では正しいデータであることを保証する
Bounded Contextから外へ出るときは、privateな情報が漏れ出ていないかを確認する