黒輔と申します。2025年にエンジニア職として復帰し1年が経ちました。この間にポートフォリオとなるようなWebアプリケーションを作成しております（継続中）。
第1回目に続く今回は、ドメイン駆動設計における戦略的設計の考えに従って、コンテキストの分割を試みたいと思います。
1. ドメイン駆動設計 (DDD) とは？
ドメイン駆動設計 (DDD) とは、"ドメイン" = "システムが解決しようとする問題領域" を中心として設計を進める、設計の考え方のことです。詳細は他の書籍やコラムに譲りたいと思います。
私はこのDDDに出会ってから、「技術は問題の解決や、ビジネス価値の増大のためにある」という考えを再確認し、その2つを実行できるエンジニアになりたいと思っています。そのため、今回はDDDの考え方を取り入れて、個人開発に活かしてみたいと思います。
2. コンテキストの分割
コンテキストの分割とは何でしょうか。
ひとくちに塗料といっても、それが塗料の商品名やメーカーといった事実情報なのか、自分が比較している対象なのか、自分の管理対象なのか...といったコンテキストの違いが存在します。これが混ぜこぜになると、ソフトウェアの価値がぶれたり、入り乱れて難解な設計・実装になってしまうので、分割しましょうというのが、DDDの「境界づけられたコンテキスト (Bounded Context, BC) 」の考えです。
前回示したプラモデルの塗料に関する課題は、以下でした。
- メーカー横断やシリーズ横断で塗料を探すため、複数のサイトを行き来したりして塗料を吟味している
- 塗料の色味の比較のため、複数のレビューサイトでの調査や実際に試し塗りをするなどして色味の違いを確かめている
- 保有している塗料を把握しきれず、似たような色を買ってしまったり、買い忘れが起きたりする
上記の塗料に関するコンテキストの違いや、課題をもとに、ソフトウェアのBCを定義します。
| ID | 名称 | 種別 | 説明 |
|---|---|---|---|
| BC1 | Selection | コア | ユーザーに、塗料比較・選定の体験を提供する。 |
| BC2 | Catalog | 補完 | 他BCやユーザーに、塗料の事実データを提供する。 |
| BC3 | Operation | 補完 | 他BCやユーザーに、塗料の在庫管理や再購入あり/なしの管理を提供する。 |
| BC4 | Auth | 一般 | 他BCやユーザーに、認証や認可を提供する。 |
コアはビジネスのコアとなるドメイン、補完はそれを支えるもの、一般はどのソフトウェアでもあるようなログイン機能といったものを指します。今回先に作る機能は「BC2: Catalog (補完)」ですが、コアとしては塗料を探し、選ぶまでの体験を提供できたらいいなと思うので、コアは「BC1: Selection」としました。もう一つの補完ドメインはOperation、つまり在庫管理や再購入のありなしを管理するドメインです。最後に、一般ドメインとしてAuth（ログイン機能などを提供）を定義します。
3. コンテキストマップ
コンテキスト同士の関係を図にしたものです。メインとしたいドメインはSelectionですが、他のBCであるCatalog, AuthはSelectionを支えるために必要です。また、OperationsはSelectionにとって不可欠ではありません。
凡例:
- 実線矢印: 依存関係（下流→上流）
- 点線: 独立関係（依存なし）
4. 今後の流れ
次回は、BC2: Catalogについてのドメインモデリングについて記事を書く予定です。
以上となります。