複数コンテキストを扱う場合のApplicationCoreの構成について

[KentaHizume]

概要

• Dressca管理アプリを作成する #1453

で作成中のDressca管理アプリについて、
ApplicationCoreの構成をどのようにするか議論したいです。

考えられるものを5パターン持ってきましたが、
別のパターンのご提案も歓迎しております。

論点

• 名前空間について、{コンテキスト}/{ドメインモデル}の順で切るべきなのか、{ドメインモデル}/{コンテキスト}の順で切るべきなのか
• プロジェクトを分割するか、名前空間のみで分割するか

コンテキストマップ

買い物と管理の2つのコンテキストが存在し、
この2つのコンテキストを横断する、カタログアイテムや注文のようなドメインモデルが存在して、
アプリケーションはコンテキストごとに作成するというイメージです。

案

個人的には3が自然に感じるのですが、ユースケースに引っ張られているだけではないかという疑惑があり、5のほうがモデル本位の設計のためベターなのではないかという懸念があります。

1：現在の実装から最も近い（コストが安い）案になります。
2,3：{コンテキスト}/{ドメインモデル}の順で切る案になります。
3,4：{ドメインモデル}/{コンテキスト}の順で切る案になります。

• 1
  

• 2
  

• 3
  

• 4
  

• 5
  

[tsuna-can-se]

ApplicationCoreのプロジェクト分割については、既に情報があります。

https://maris.alesinfiny.org/app-architecture/overview/application-structure/#solution-structure

基本的には業務の観点で切った後、レイヤーの観点でプロジェクトを分割します。
また、ロールの観点でプロジェクト分割することは原則ありません。
ただし、プレゼンテーション層のプロジェクトの場合は、一般ユーザー向けWeb、管理者向けWeb、のように、ロールで入り口から分割することは一般的です。

[KentaHizume]

@tsuna-can-se
ご確認いただきありがとうございます。
コンテキストの概念とロールの概念を混同しておりました。
ロールが増えることによって生じるのはユースケースのバリエーションであり、
コンテキストが増えるわけではないと理解いたしました。