基本原則

オニオンアーキテクチャに則る

• 内側（ドメイン層）は外側（インフラ層）に依存しない
• 依存の向きは外→内
• 依存性逆転の原則を守る
• アプリケーションはフレームワークやエンジンから疎結合であるべき

各層におけるECSの要素の配置方針

コンセプトと実装方針

Component（IComponentData）はDTOとして扱う

• Unity.Entitiesに依存するため、ドメイン層には置かない
• ドメイン層のモデルと相互変換できるMapperを作る
• ComponentはInfrastructure/Componentsに置く

Entityの抽象化

• Unity.Entities.Entityをアプリケーション層で使ってはいけない
• IEntityHandleをドメイン層で定義し、Unity依存のUnityEntityHandleをインフラ層で実装
• アプリケーション層のユースケースはIEntityHandleを通じてエンティティを扱う

SystemBase（ECS処理）の責務

• ECSのSystemBaseはあくまで ランナー
• 処理はユースケースに委譲
• DIライブラリを使ってUseCaseに注入して実行

依存性逆転の具体化

• IXxxxServiceのようなドメインサービスの抽象を定義
• ECSXxxxServiceがその実装となり、EntityManagerなどを使う
• DIライブラリでバインドしてインフラ層の実装をアプリ層に注入

Mapperによる変換責務の分離

• XxxxComponent ⇔ Xxxx の相互変換を担うXxxxMapperを作成
• インフラ層でのみUnity依存の型を扱う

ディレクトリ構成例

MyGameProject/
├── Domain/
│   ├── Entities/        ← IEntityHandleなど
│   ├── Models/          ← Xxxxなどのドメインモデル
│   └── Services/        ← IXxxxServiceなどのインターフェース
│
├── Application/
│   └── UseCases/        ← XxxxUseCaseなど
│
├── Infrastructure/
│   ├── Components/      ← XxxxComponentなどECSのDTO
│   ├── Services/        ← EcsXxxxServiceなど
│   ├── Systems/         ← XxxxSystemなどSystemBase
│   ├── Mappers/         ← Componentとモデルの相互変換
│   └── Entities/        ← UnityEntityHandleなど
│
├── Presentation/
│   └── MonoBehaviours/  ← UIや入力など
│
└── Installers/          ← DIライブラリによるバインド

依存関係

[ Unity / ECS / Zenject ]
         ↑
[ Infrastructure ] ← ECS System, Component, Service実装
         ↑
[ Application ] ← UseCase（抽象的にEntity操作）
         ↑
[ Domain ] ← EntityHandle, Service Interface, Business Model

注意点

• コンポーネントは軽量データのみで定義（DTO）
• ドメイン層のロジックはユースケース層で必要なときだけ取り出して適用
• 大量の同期・変換を避け、最小限のデータアクセスにとどめる

これを守ることで、ECSを活かしつつビジネスロジックをテスト可能・メンテしやすく保つというバランス型設計が可能