前回の記事
【ミライトデザイン社内勉強会#11】「IDDD本から理解するドメイン駆動設計」輪読会~第2章「ドメイン」「サブドメイン」「境界づけられたコンテキスト」を読み解く~ - Qiita
実践DDD本 第3章「コンテキストマップ」～「境界づけられたコンテキスト」の関係を俯瞰する地図～ (1/3)：CodeZine（コードジン）
コンテキストマップとは
- 複数の「境界づけられたコンテキスト」間の関係を俯瞰する図で、システムの全体像や相互関係を把握する
- システム間の関係を把握できる
巨大な泥団子
- 大きな泥だんご - Wikipedia
- レガシーなシステムにありがち
- 巨大な泥団子の中にあるクラスなどに依存してしまうと新規のシステムも泥団子の一部になってしまう
- 泥団子の一部にならないように新規のシステムはコンテキストを泥団子から分け、泥団子とはPublished Languageのみでやりとりをして、腐敗防止層を作成するなどする
公表された言語（Published Language）
- 例えば、APIを叩いた時にJSONで連携するみたいな
- コンテキスト間のやりとりはPublished Languageのみで行う
腐敗防止層
- Adapterパターンとかを使って依存しないようにするとか？
- というよりかはほとんどがマッピング作業になると思う
- 外からきたデータをそのまま使う前提だと、例えばJSONでnullがこない前提のデータにnullが入っていたらエラーになってしまう。
- 不正なデータがあればエラーを出して弾くとか
- nullを適切な値（空文字とか）に変換するしてシステムが落ちないようにするとか
- 単純に言えばマッピング作業
- 顧客のデータがJSONで連携されたら、システムの内部で使用するモデルに変換するみたいな
1アプリケーションないに複数コンテキストがあってもいいが、別コンテキストの情報は使えない
- 1アプリケーション内に1コンテキストが理想ではあるけど
- 1アプリケーション内に複数コンテキストがある場合でも、コンテキスト間のやりとりはPublished Languageでのみやりとりをする
- 別のコンテキスト内のクラスを使うことはない
- 同じクラスを使っていると依存関係が発生してしまうので
- 別のコンテキスト内のクラスを使うことはない
- コンテキストはクラスのカプセル化みたいなも
- 使う側は内部の実装をしる必要はない
- Published Language（公表された言語）のみを知っていればいい
コンテキストマップを書くときに、U（Upstream）とD（Downstream）以外書くことって実際あるの？例えばACLとか
- 認識さえ共有できていれば、書いても書かなくてもいいと思う
- 情報は多い方がいいけど、必要に応じて
境界づけられたコンテキスト間の連携方法を示す「統合パターン」に「共有カーネル」があるが、コンテキスト間でクラスを共有することもあるの？
- https://codezine.jp/article/detail/9837?p=2
- 基本はやらない方がいい、
- 完全に全く同じコードとかであれば、共有することもあるかも
- でも、依存関係になってしまうので、やめた方がいい
- 別のコンテキストで使われている可能性もあるので気軽にさわれない
- せっかくコンテキストを分けたのに、同じ言語で書かないといけないなどの縛りも出てくる
次回
【ミライトデザイン社内勉強会#13】「IDDD本から理解するドメイン駆動設計」輪読会~第4章「アーキテクチャ」~ - Qiita