「境界付けられた コンテキスト間の関係」 についてもっと語ろう @acomagu 240907
 

自己紹介 - @acomagu github.com/acomagu
 - s1230004
 - 株式会社デザイニウムで主に TS を書いています
 - 最近はスプラトゥーンにハマっています
 - 会津に帰りたい
 - 入っていたサークル: Zli / 合唱部
 

もくじ 1. BC(境界付けられたコンテキスト)は身近である
 2. BC 間の関係の種類
 3. 知っておくと何がいいのか？
 

BC(境界付けられたコンテキスト) は身近である 

BC(境界付けられたコンテキスト)とは？ 「チームの形がシステムの形を決める」(逆コンウェイの法則)
 ≒ コミュニケーションの境界が技術の境界になる
 
 DDD「1つの境界付けられたコンテキストに複数のチームが取り組むのは、(不可能とは 言わないが)難しい」
 →チームの境界あるところにコンテキスト境界あり
 - チームが異なる
 - ユビキタス言語が異なる
 - 目的が異なる
 ↑別 BC のサイン
 

BC(境界付けられたコンテキスト)とは？ フロントエンド/サーバーサイドは別境界
 ライブラリは別境界
 SaaS/BaaS は別境界
 

BC(境界付けられたコンテキスト)とは？ フロントエンド/サーバーサイドは別境界
 ライブラリは別境界
 SaaS/BaaS は別境界
 Stripe サーバーサイド フロントエンド BC BC BC レガシー サーバーサイド BC 

BC 間の関係の種類 それぞれざっくり 

BC 間の関係の種類①: 共有カーネル 一部モデル(ソースコード)が共有されている関係
 初期は開発が速く進みやすい
 (インフラ等ドメイン外の共有については共有カーネルとは言わない)
 

BC 間の関係の種類②: 顧客/供給者の関係 > 二つの開発チームに上流/下流関係があり、上流のチームが成功するかどうかが下 流の結果に左右されうる場合 (IDDD)
 > 一方のサブシステムが、本質的にもう一方のサブシステムに対して入力を与える関係 の場合 (DDD)
 「下流が上流を使う」ような、依存関係だと解釈しています。
 供給者には、顧客の要求が重要であり、要求に答えるモチベーションがある
 例: (JSON 色付け的な)サーバーサイド/フロントエンド
 

BC 間の関係の種類③: 順応者 二つの開発チームに上流/下流関係があるが、
 上流には、下流の要求に答えるモチベーションがそこまでないが
 しかし “上流の設計の品質がそれほど悪くなく、スタイルもそれなりに互換性がある場 合”
 つまり、「上流のモデルを流用する」
 
 

BC 間の関係の種類④: 腐敗防止層 一方が本質的にもう一方の入力となるが、
 上流には、顧客の要求に答えるモチベーションがそこまでないが
 しかし “カプセル化の欠如や、ぎこちない抽象、下流チームでは使用できないパラダイ ムを用いたモデリングなどにより、その設計を扱うのが難しすぎる場合、下流チームは やはり独自のモデルを開発する必要がある”
 つまり「上流がイケてないので、上流とは別のモデルを作る」
 
 

BC 間の関係の種類⑤: 別々の道 統合しない
 別サービスとしてビルドする
 (e.g. ユーザーが使いたいサービスをメニューから選ぶ、など)
 

この図ではそれぞれどんな関係だろう？ Stripe サーバーサイド フロントエンド BC BC BC レガシー サーバーサイド BC 

この図ではそれぞれどんな関係だろう？ Stripe サーバーサイド フロントエンド BC BC BC レガシー サーバーサイド BC 順応者
 腐敗防止層
 顧客/供給者
 ※一例
 

知っておくと何がいいのか 

知っておくと何がいいのか 多分一人で開発している場合にはあまり考えなくても問題にならない
 別の人に「この別システム/ライブラリをコード上でどう扱うか」という態度を説明したいと きに役に立つ
 

知っておくと何がいいのか？ 例えば「アプリケーションにライブラリ A とライブラリ B を統合する場合」
 アプリケーション B A 「A はドメインから直接使うが、B は一旦インフラを挟みたい...」 →なぜ？(レビューで指摘されたと思ってください) (例えば、 A は日付ライブラリで B は何かの SDK) 

知っておくと何がいいのか？ A は「モデルがイケてるので、ドメインが直接触るほうがいい」
 > 上流チームのモデルに隷属することで生じる、境界付けられたコンテキスト感での複 雑な変換を取り除くこと。確かに下流の設計者がとれるスタイルは制限され、そのアプリ ケーションにとって理想的なモデルが作れなくなるかもしれないが、順応することを選ぶ ことで統合は大幅に簡略化されるのだ。
 

知っておくと何がいいのか？ B は「モデルの一部分しか使わないので、腐敗防止層を通してこちら側のモデルに適用 したい」
 

知っておくと何がいいのか 他にも、フロントエンドのバックエンドの関係において、「顧客/供給者の関係を目指し て、テストをしっかりバックエンドで用意したほうがいい」という会話ができるかも
 

大切なのは語彙を増やすこと - 「DDD 本のパターンに従うべき」なんて今どきみんな食傷していて(私も)、そんなこ とよりもっと自分のプロダクトを見つめたほうがいい
 - このあたりは「DDD とは結局何なのか(acomagu SpeakerDeck にあります)」も良ければ見てみてく ださい
 - しかし、まさに自分が書くソースコードの構成要素について、チーム内で話せる共 通語彙が増えるのはいいこと
 - DDD 本や IDDD 本には今回紹介した関係性それぞれについてもっといろいろな ケースが載っている
 「DDD」というだけで拒絶するのではなく、その部分だけでも読んでみてみてください
 

みなさんも自分のソースコードについて BC を見つけ BC 間の関係を考えてみてください ありがとうございました!