Spring Modulith を検証し、必要に応じてブランクプロジェクトに取り込む

[kharada7]

現在の機能やドキュメントに関する問題点

Spring Modulith がリリースされてしばらく経過するが、未検証である。
https://github.com/spring-projects-experimental/spring-modulith

必要な解決策

Spring Modulith を検証し、ブランクプロジェクトに組み込むことが可能であれば組み込む。

良い影響と悪い影響

No response

影響範囲

No response

確認

• 要求しようとしている機能およびドキュメントが、既に Issues や プルリクエスト 、 Discussions に登録されていないことを確認しました。
• 私たちの 行動規範 に従うことを同意します。

[kenjiyoshid-a]

モジュラーモノリスとDDDを両立しているプロジェクト例

• https://speakerdeck.com/kawauso/kuroharunakonhauntozhan-lue-wozhi-erumosiyuramonorisutotomeinqu-dong-she-ji

[kenjiyoshid-a]

検討

以下、オーケストレーターのアプリケーションサービスをアプリケーションサービス、モジュールに閉じたアプリケーションサービスをモジュールサービス（仮称）とします。

• アプリケーションサービスの役割
  • ユースケースの表現（モジュールサービスの操作）
  • ログ出力
  • トランザクション境界（@transactional）

⇒ モジュールサービスに定義された業務ルール適用済みCRUDを呼び出し続けるものになる？？

• モジュールサービスの役割
  • モジュールに閉じた処理
  • エンティティを用いた業務ルールの適用
  • リポジトリの操作

⇒ 業務ルールが適用された CRUD になる？？

命名規則

AssetsApplicationService（オーケストレーター）
AssetsService（モジュールに閉じたサービス）
AssetsDomainService（ドメインサービス）
Assets（エンティティ）
AssetsRepository（リポジトリインタフェース）
MyBatisAssetsRepository（リポジトリ実装）

[kenjiyoshid-a]

フォルダー構成

root/
├─ modules/src/
│  ├─ orchestrator/
│  │  └─ xxApplicationService.class
│  ├─ aaaDomain/
│  │  ├─ aaaService.class
│  │  ├─ exception/
│  │  │     └─ xxException.class
│  │  └─ internal/
│  │     ├─ domain/
│  │     │  ├─ aaaDomain.class（公開、プレゼンテーション層への返却のため）
│  │     │  ├─ aaaDomainService.class
│  │     │  ├─ aaaRepositoryInterface.class
│  │     │  └─ valueObject.class
│  │     └─ infrastructure/
│  │        └─ aaaRepositoryImpl.class
│  ├─ bbbDomain
│  ├─ cccDomain
│  ├─ common（共有カーネル）/
│  │  ├─ utils/
│  │  ├─ log/
│  │  ├─ constants/
│  │  └─ exception/（共通例外）
│  └─ authorization（認証モジュール/共有カーネル）/
├─ web/
├─ web-admin/
├─ web-consumer/
└─ batch/

[kenjiyoshid-a]

会計情報の値オブジェクトを買い物かごのシナリオと注文のシナリオで共有しているのが気になる。

[kenjiyoshid-a]

現状の想提案だとサブモジュールが分割されすぎている感があるので、DDDの境界付けられたコンテキストでモジュールを切った方が良い。コンテキスト境界でモジュールを切る際に、どのような基準できるべきなのかを考える必要がある。

[kenjiyoshid-a]

区切られた文脈とは

ソフトウェア構築をする上で役に立つモデルを構築するための境界のこと。
区切られた文脈の中では、同じ言葉は同じ意味を持つ。

同じ言葉で異なる意味を持つものの例として、「ユーザー」という言葉がある。
ある業務では「ユーザー」はシステムを利用する人を指すが、別の業務では「ユーザー」はシステムを管理する人を指す場合がある。
また、「注文」という言葉も、ある業務では顧客が行う購入のことを指すかもしれませんが、別の業務では在庫管理のための発注のことを指す場合がある。
同じ言葉が異なる意味を持ち始めるポイントが区切られた文脈の境界となる。

[kenjiyoshid-a]

区切られた文脈を用いた場合のフォルダー構成

root/
├─ web（web-adminとweb-consumerの共通部品）
├─ web-admin（管理者用のプレゼンテーション層）
├─ web-consumer（利用者用のプレゼンテーション層）
├─ batch（バッチアプリケーションのプレゼンテーション層）
└─ modules（モジュール）/
   └─ src/java/main/modules/
      ├─ shopping（購買のコンテキスト）/
      │  ├─ ShoppingApplicationService.java
      │  ├─ CatalogApplicationService.java
      │  ├─ OrderApplicationService.java
      │  └─ internal/
      │     ├─ domain/
      │     │  ├─ Catalog.java
      │     │  ├─ …
      │     │  ├─ value-object/
      │     │  │  ├─ Address.java
      │     │  │  └─ …
      │     │  └─ repository/
      │     │     ├─ CatalogRepository.java
      │     │     └─ …
      │     └─ infrastructure/
      │        ├─ MyBatisCatalogRepository.java
      │        └─ …
      ├─ catalog-management（カタログ管理のコンテキスト）
      ├─ assets-management（静的アセットのコンテキスト）
      ├─ authorization（認証のコンテキスト）
      └─ common（共通部品）

ユースケースがコンテキストの境界を跨ぐことはない。
コンテキストが複数のプレゼンテーション層から利用されることはある。
AlesInfiny Maiaでは、過剰な実装を避けるため、エンティティをプレゼンテーション層に公開する。