複数の境界づけられたコンテキストにおける 共通ロジックの扱いについて Showcase Gig Inc. プロダクト開発チーム TL 鈴木

Showcase Gig - 最近の悩み 複数の境界づけられたコンテキストがあるとき 共有したいモデルやユースケースは どのように扱うべきか

用語の確認 境界づけられたコンテキスト ● ドメインの問題を技術的ソリューションで解決するもの ● 巨大なモデルを構築しないためにユビキタス言語の境界に従 い分割

その悩みはおかしいのではないか？ ・・・と思う人もいるかもしれません モデルを定義・適用する境界を明示的に示した結果 作られるものが境界づけられたコンテキストなんだから、 共有したいユースケースやモデルなんてある方がおかしいのでは 🤔

境界づけられたコンテキストの例 実際には特定のドメインの 問題解決に複数システムが 関わることがある 『実践ドメイン駆動設計』 第2章 ドメイン、サブドメイン、境界づけられたコンテキスト より

私たちのシステム （プロダクトバックエンド） ※実際のシステムから表現を 変更・簡略化しています ビジネスのルールが 変わる単位で分割 ドメインは モバイルオーダー

私たちのシステム （プロダクトバックエンド） ※実際のシステムから表現を 変更・簡略化しています

課題の再確認 複数の境界づけられたコンテキストがあるとき 共有したいモデルやユースケースは どのように扱うべきか

課題の具体例 注文モデルは コンテキスト ごとに異なる 注文商品モデルは共通 ドメインモデルや それを利用する処理が重複しがち

モジュラモノリスとして実装

単純にコードを流用すると 異なるコンテキストのユースケースを呼び出してしまうことに モジュール化とは🤔

考えられるアプローチ 1. 1つのシステムとして扱う ○ イートイン、テイクアウトを統合 ■ pros: ロジックの重複を排除できる ■ cons: DDDとは真逆のアプローチ😕 2. モジュール分割の観点を変える ○ サブドメイン[注文] と [商品] ○ テイクアウトやイートインのモジュールから呼び出す ■ pros: モデルの重複を排除できる ■ cons: 正しく分割するのが難しい ● 商品モデルに「イートイン」専用の属性・振る舞いができたら？