黒輔と申します。2025年にエンジニア職として復帰し1年が経ちました。この間にポートフォリオとなるようなWebアプリケーションを作成しております（継続中）。
第2回目はコンテキストの分割を試みましたが、続く今回はドメインモデリングをやってみたいと思います。
1. ドメインモデリング
前回では、他BCやユーザーに、塗料の事実データを提供するコンテキストを"Catalog"としました。今回は、Catalogコンテキストの主要な概念、その属性、それらの関係性を定義していく「ドメインモデリング」を行っていきたいと思います。
『つくりながら学ぶ！ドメイン駆動設計 実践入門』（マイナビ出版）によると、ドメインモデリングは以下のステップで行われます。
1. 集約とポリシーの表現
2. ビジネスルールの具体化
3. 必要なインプットの特定
4. アウトプットの明確化
また、アプローチとしては、「ビジネスの核となる機能やロジックを最初に特定し、それを実現するために必要な属性やエンティティを導き出す」というアプローチをとることになります。
2. 検索機能のイメージ
塗料の検索機能を作成したいわけですが、どのように塗料を絞り込みしたいか？どういった検索ロジックやビジネスルールがあるか？から考えて、概念や属性を特定していきたいと思います。
まず、塗料を絞り込みしたいときに必要な属性を考えます。
- 塗料の色分類（赤系、青系など）
- ブランド（GSIクレオス、タミヤ、ガイアノーツなど。つまり、塗料のメーカー）
- 溶剤のタイプ（ラッカー系、アクリル系、エナメル系など。絵の具で言うなら水性とか油性とか）
- 光沢（ツヤがあるか、ないか）
- 用途（下地塗装なのか、それともトップコート用なのか、など）
- ジャンル（ガンプラ向けなのか、ミリタリーモデル向けなのか、フィギュア向けなのか）
- 特殊効果（メタリック塗料なのか、クリアー塗料なのか、など）
- その他、自由なラベリング（将来拡張）
これらに加えて、塗料の情報として検索結果に欲しい属性を考えます。
- 名称（商品名）
- 色の見本
- 価格
- 内容量
- 商品画像
これで、一通り属性を挙げることができました。
これらの関係性は、まず1対1となるものは
- 名称
- 色見本コード
- ブランド
- 溶剤のタイプ
- 光沢
- 型番
- 価格
- 内容量
- 商品画像
次に、1対多となるものは
- 色の分類（塗料によっては、例えば緑と青の中間のような色など、複数ラベリングしたい場合もある）
- 用途
- ジャンル
- 特殊効果
- その他、自由なラベリング
こういったイメージをすれば、以下のステップがスムーズに進みます。
3. 集約とポリシーの表現
集約として、1つ目は Paint を定義します。次に、1対多となるラベリング（前述した色の分類など）をするための集約として Tag を定義します。
| ID | 名称 | 説明 |
|---|---|---|
| AR1 | Paint | 塗料のデータ。 |
| AR2 | Tag | 本アプリで定義した、塗料をラベリングするためのタグ。 |
4. ビジネスルールの具体化
4.1. AR1: Paint
- 塗料の事実データを表す
- 以下の属性をもつ（1対1）
- 名称
- 色見本コード (HEX形式、RGB形式、HSL形式で保持する）
- ブランド
- 溶剤のタイプ
- 光沢
- 型番
- 価格
- 内容量
- 商品画像
- 以下の属性を持つ（1対多）→Tagとして保持する
- 色の分類
- 用途
- ジャンル
- その他、自由なラベリング
4.2. AR2: Tag
- 塗料に対してラベリングするための機能を提供する
- 以下の属性を持つ
- 表示名
- タグのカテゴリー
5. 必要なインプットの特定
先述した属性に加えて、PaintやTagなどのIdが想定されます。
6. アウトプットの明確化
ここでは、検索結果に表示するPaintSummaryと、詳細ページに表示するPaintDetailを定義しました。
| ID | 名称 | 説明・ルール |
|---|---|---|
| OP1 | PaintSummary | 塗料の概要を示す必要最小限のアウトプット。塗料名、ブランド、色見本、基準色との距離（類似色検索の場合）を保持する。 |
| OP2 | PaintDetail | 塗料の詳細な情報を示すアウトプット。 |
7. 集約間の関連性の定義
本コンテキストの集約はPaintとTagでした。これらの関係性は、以下の通り「多対多」です。
8. まとめ
以上の通り、ざっくりとドメインモデリングを行いました。まだ詰めが甘いところもあるかもしれませんし、本来ならもう少し、ドメインエキスパートと技術者がじっくりと対話とすり合わせを重ねて詰めるところだと思います。
今回までの成果は、前回のサービス企画、コンテキスト分割含めて、markdown文書化し任意のフォルダやリポジトリに保存しておきます。markdown文書化するのは、ExcelなどよりもAIエージェントやGitでのバージョン管理に向いているためです。後々でAIに読み込ませて設計レビューやコーディングを行ったり、Gitバージョン管理することを想定しています。
次回からは、ユースケース定義に入っていきます。