dackdive's blog

新米webエンジニアによる技術ブログ。JavaScript(React), Salesforce, Python など

IDDD本もくもく読書会メモ#2（第3章 コンテキストマップ）

DDD

第1回 に続いて第2回も無事に開催することができました。

※社外からの参加者もお待ちしています（Slack グループ）

教材

実践ドメイン駆動設計

実践ドメイン駆動設計

Amazon

書籍に加え、前回見つけた CodeZine の解説記事

今回は書籍の前に目を通したが、最初に概要を掴んでから書籍に入れるので効果的。今後もこの進め方でいきたい。

第2回で読んだ範囲

第3章を一通り。この章はボリュームが小さくて助かった。


学習メモ

第2章で「境界づけられたコンテキスト」を学んだが、「コンテキストマップ」は複数の「境界づけられたコンテキスト」の関係を俯瞰する図となる。
抽出したコンテキストを線で結び、互いの関係性を整理していくイメージ。

f:id:dackdive:20170717225955p:plain:w320

（図は書籍より引用）

2 つのコンテキスト間にはどちらかが上流（Upstream）でどちらかが下流（Downstream）という関係がある。図中には U または D で書く。

プロジェクトの現状を示す図。こうあって欲しいという将来の図ではない。

コンテキストマップを書く理由

http://codezine.jp/article/detail/9837 より引用。

コンテキストマップを描くことによって、システム間の関係を適切に把握できるメリットがあります。DDDチームは既存システムとの連携方法を把握でき、他チームとのコミュケーションの必要性を判断できるようになります。

　コンテキストマップはアーキテクチャ図というよりも、チーム間のコミュケーション関係を示す図の意味合いが強くなります。コンテキストマップは組織間の問題を見つけ出せる唯一のドキュメントとなるため、プロジェクトの成功に不可欠といわれています。

コンテキストマップの分類

境界づけられたコンテキスト間の関係には、いくつか名前の付いた種類がある。
これは CodeZine で解説されているように、まず大分類として

  1. チーム間の関係を示す「組織パターン」
  2. データとプログラムの連携方法を示す「統合パターン」

に分けて考えると理解しやすい。（書籍では全部いっしょくたにしているが）

  1. チーム間の関係を示す「組織パターン」
    • パートナーシップ
      • 2つのコンテキストを担当するチームが協力的な関係にある
    • 別々の道
      • コンテキスト間で統合を行わない
    • 順応者
      • 上流側が下流側の要求に応える必要がない
      • 例：Twitter や GitHub などの API を使った場合
    • 顧客／供給者
      • 上流のチームが成功するかどうかが下流の結果に左右されうるという場合、上流（供給者）は下流（顧客）のニーズに対応する必要がある
      • 例：モバイルアプリ開発における、API 開発チーム（上流）とアプリ開発チーム（下流）
  2. データとプログラムの連携方法を示す「統合パターン」
    • 共有カーネル
      • 複数ドメインにおいて共有が必要な部分に、共通で使用するドメインモデルを構築してソースコードレベルで共有する
      • 共有カーネルに変更が必要な場合は他のチームの承認が必要になるため、この部分は極力小さくする
    • 巨大な泥団子
      • （既存システムなど）大規模で複雑なものを、そのまま（適切なモデルに分割せず）大きな塊として捉えること
    • 公開ホストサービス（OHS：Open Host Service）
    • 公表された言語（PL：Published Language）
      • 2 つの境界づけられたコンテキスト内にあるモデル同士で変換するための、共通の言語
      • OHS と組み合わせて使うことが一般的
      • 例：JSON
    • 腐敗防止層（ACL：Anti Corruption Layer）
      • 下流側が上流側の機能を自コンテキストのドメインモデルに変換するレイヤ
      • 上流側と協力関係が築けなかった場合に、上流側に振り回されないように設ける変換層
コンテキストの分析と統合ポイント

境界づけられたコンテキストが適切に分割されているかを分析し、複数の概念が 1 つのコンテキストの中に混じっていた場合は Brandolini の記法では三角の警告アイコンを記載する。

f:id:dackdive:20170717235155p:plain:w320

（図は書籍より引用）


ディスカッションメモ

  • OHS と PL のどちらか一方だけしか使われないことってあるんだろうか

→ あんまりなさそう

  • 競合ポイントはどうやって見つけるのか

書籍に出てきた図が（ひょうたん型になっていて）恣意的な感じが...

  • リモートモデル、ローカルモデルとかのくだりがよくわからない

自立性を確保するには、依存するオブジェクトの状態をローカルシステム側に保持しておけばいい。依存するオブジェクト全体をキャッシュしておけばいいと考える人もいるかもしれない。しかし、DDDでは、この考え方は一般的ではない。その代わりに、ローカルのドメインオブジェクトを作って外部のモデルをそれに変換し、ローカルのモデルに必要な最小限の状態だけを保持する。

→ たとえば、GitHub API を使って Issue 管理アプリを作るとき、

  • API で Issue を GET した結果のプロパティをアプリ内で全部保持するわけはなく、実際には必要なものだけ保持するはず
  • API に仕様変更があったときにも影響を最小限にするため、レスポンスをそのまま使うのではなく何らかのオブジェクトに変換して使うはず（ACL にもなる）

というわけで、API のレスポンスを加工してアプリ内で使うためのモデルに変換する、というのはここに記載されたことそのものズバリな気がする。


次回

7/21（金）19:00 頃からやります。


資料

見つけたものをどんどん追加していきます。