ddd-architecture-selector

DDD アーキテクチャ選定ガイド

プロジェクトの状況（チーム規模、ビジネスの複雑さ、技術スタック、インフラの変更頻度、エコシステムの選好）に照らして、5 つの DDD アーキテクチャパターン（レイヤード、オニオン、ヘキサゴナル、クリーン、COLA）を評価するアーキテクチャ選定ガイドです。

ワークフロー

ステップ 1：プロジェクトの状況を収集する

• チーム規模と DDD の経験レベル
• ビジネスの複雑さ（シンプルな CRUD／中程度／高）
• 技術スタック（Spring Boot／Go／Node.js／.NET／Python）
• インフラの変更頻度（低／中／高）
• 複数のエントリーポイントの必要性（REST + CLI + MQ + gRPC？）
• テストカバレッジの要件（単体／結合／E2E）
• エコシステムの選好（中国のコミュニティ／国際的なコミュニティ）

ステップ 2：判断マトリクスを実行する

• 7 つ以上の観点から 5 つのアーキテクチャを比較する

ステップ 3：判断ツリーを適用する

• 複雑さ → チーム規模 → 技術スタック → 推奨アーキテクチャ

ステップ 4：CQRS のレベルを推奨する

• L0：なし、L1：モデル分離、L2：データベース分離、L3：イベントソーシング

ステップ 5：ドメインの種類を分類する

• コア／汎用／支援 → ドメインごとに異なるアーキテクチャを適用する

ステップ 6：マイクロサービスへの分割を提案する

• 1 つの BC → 1 つのサービス。統合・分割のルールも示します

ステップ 7：具体的なアーキテクチャスキルに案内する

• 詳細な実装ガイドへのリンク

使用する場合（および使用しない場合）

✅ 使用する場合	❌ 使用しない場合
新しいプロジェクトを開始し、アーキテクチャの決定が必要な場合	アーキテクチャがすでに決まっている場合 → 該当するスキルに直接進む
複数の DDD アーキテクチャを比較する場合	DDD の学習だけが必要な場合 → ddd-architecture-awesome を使用する
チームが最適なアプローチを判断できない場合	既存プロジェクトのアーキテクチャ評価が必要な場合 → ddd-architecture-evaluator を使用する
マイクロサービスへの分割戦略を計画する場合	選定後にドメインモデリングが必要な場合 → ddd-domain-designer を使用する
CQRS の必要性を評価する場合	DDD ではないプロジェクトを評価する場合（標準的な MVC を検討してください）
中国のエンタープライズチームが技術選定を行う場合	DDD が不要なシンプルな CRUD の場合 → 標準的な MVC を使用する
チーム規模や DDD の成熟度が不明な場合	既存の DDD コードのコードレビューが必要な場合 → ddd-code-reviewer を使用する

境界

カテゴリ	説明	代替手段
✅ 対応範囲	新規プロジェクトのアーキテクチャ選定（5種類のDDDアーキテクチャ）	—
✅ 対応範囲	移行判断のためのアーキテクチャ比較	—
✅ 対応範囲	CQRS／イベントソーシングの必要性評価	—
✅ 対応範囲	ドメインの分類（コア／汎用／支援）	—
✅ 対応範囲	境界づけられたコンテキストに基づくマイクロサービスの分割	—
✅ 対応範囲	チーム規模からアーキテクチャへの対応付け	—
⚠️ 要件	基本的なプロジェクトの状況：チーム規模、ビジネスの複雑さ、技術スタック	—
⚠️ 要件	分類にはドメインエキスパートまたはプロダクトオーナーの参加が必要です	—
❌ 対象外	アーキテクチャがすでに決定している場合は、このスキルを使用しないでください	ddd-architecture-layered / ddd-architecture-onion / ddd-architecture-hexagonal / ddd-architecture-clean / ddd-architecture-cola（それぞれ次のコマンドでインストールします：npx skills add full-stack-skills/ddd-skills --skill <name>）
❌ 対象外	DDD の学習や概念の理解だけが目的の場合は、このスキルを使用しないでください	ddd-architecture-awesome（インストール：npx skills add full-stack-skills/ddd-skills --skill ddd-architecture-awesome）
❌ 対象外	既存アーキテクチャの健全性と品質を評価する場合は、使用しないでください	ddd-architecture-evaluator（インストール：npx skills add full-stack-skills/ddd-skills --skill ddd-architecture-evaluator）
❌ 対象外	アーキテクチャ選定後のドメインモデリング／集約設計には使用しないでください	ddd-domain-designer（インストール：npx skills add full-stack-skills/ddd-skills --skill ddd-domain-designer）
❌ 対象外	DDD 準拠に関するコードレビューには、このスキルを使用しないでください	ddd-code-reviewer（インストール：npx skills add full-stack-skills/ddd-skills --skill ddd-code-reviewer）
❌ 対象外	DDD を採用しない／標準的な MVC プロジェクトには、このスキルを使用しないでください	標準的な MVC ガイドを使用してください（DDD スキルではありません）

対象ユーザー

このスキルは、バックエンド開発者（DDD アーキテクチャの実装担当）、ソフトウェアアーキテクト（パターンの評価と選定担当）、テックリード（チームの実装をレビューする担当）、および DDD 初学者（ドメイン駆動設計の基礎を学ぶ方）向けに設計されています。

ルール

1. アーキテクチャの選定では、少なくとも5つの側面を評価する必要があります。
2. イベントソーシングを既定で推奨しないでください。L2 CQRS が成功した後にのみ推奨します。
3. 選定では、チーム規模とドメインの複雑さを最優先の要素にする必要があります。

5種類のアーキテクチャの判断マトリクス

評価項目	Layered	Onion	Hexagonal	Clean	COLA
学習コスト	★☆☆	★★★	★★★	★★★	★★☆
ビジネスの複雑さへの適合性	★☆☆	★★★	★★★	★★★	★★★
CRUD の効率性	★★★	★☆☆	★☆☆	★☆☆	★★☆
インフラの置き換えやすさ	★☆☆	★★★	★★★	★★★	★★☆
テストのしやすさ	★☆☆	★★★	★★★	★★★	★★★
中国語コミュニティ	★★★	★☆☆	★☆☆	★☆☆	★★★
コード生成のサポート	良好	不十分	不十分	不十分	優秀
モジュールの物理的な分離	低	中	中	高	高
進化の道筋の明確さ	★☆☆	★★★	★★★	★★★	★★★
適合するチーム規模	1-5	5-15	5-15	15-50	5-50
起源	Martin Fowler	Jeffrey Palermo（2008）	Alistair Cockburn（2005）	Robert C. Martin（2012）	Alibaba（2018）

アーキテクチャ	最適な用途	避けるべき状況
Layered	シンプルな CRUD、小規模チーム、従来型 MVC からの移行	複雑なビジネスルール、インフラの頻繁な変更
Onion	高いテストカバレッジ、インフラの変更	CRUD が中心のアプリ、抽象化の経験がないチーム
Hexagonal	複数のエントリーポイントを持つシステム、マイクロサービスの標準化	単一エントリーポイントのシンプルな CRUD、迅速なプロトタイプ
Clean	大規模なエンタープライズシステム、厳格な物理的分離	小規模チーム（<5）、迅速な MVP の反復
COLA	中国の Spring Boot エコシステム、エンジニアリング標準	Java 以外の技術スタック、国際的なチーム

3ステップの判断ツリー

ステップ 1：ビジネスの複雑さを評価する

Business Complexity?
│
├── Simple CRUD (80%+ CRUD operations)
│   └── Planning DDD adoption in future?
│       ├── No  → LAYERED ARCHITECTURE
│       └── Yes → COLA Simplified (single module)
│
├── Moderate (core business logic with rules)
│   ├── Chinese ecosystem / Spring Boot + MyBatis?   → COLA
│   ├── Value domain layer purity most?               → HEXAGONAL
│   ├── Multi-entry system (REST + CLI + MQ)?         → HEXAGONAL
│   ├── Infrastructure changes often?                 → HEXAGONAL / ONION
│   └── .NET / Python stack?                          → ONION
│
└── High (multiple BCs, microservices)
    ├── Enterprise / international team?              → CLEAN ARCHITECTURE
    ├── Chinese enterprise, per-service standards?     → COLA (multi-module)
    ├── Mixed tech stack per service?                 → HEXAGONAL per service
    └── Need microservice + standard per module?      → COLA + HEXAGONAL hybrid

ステップ 2：チームの規模に合わせる

チームの規模	推奨アーキテクチャ	理由
1-5	Layered または COLA の簡易版	手続きが最小限で、最も迅速に開発できます
5-15	Hexagonal / Onion / COLA（単一モジュール）	抽象化と生産性のバランスが取れています
15-50	Clean / COLA（マルチモジュール）	物理的に分離でき、チームで並行して作業できます
50+	マイクロサービス + サービスごとの Hexagonal	チームが自律的に動け、独立してデプロイできます

進化の道筋：チームの成長に合わせて、アーキテクチャを段階的にアップグレードします。1-5（Layered）→ 5-15（Hexagonal）→ 15-50（Clean/COLA）→ 50+（Microservices+Hex）。

ステップ 3：最終的な推奨

次の条件に当てはまる場合	選択するもの	理由
Spring Boot + MyBatis + 中国のチーム	COLA	エコシステムとの適合性、中国語のドキュメント、スキャフォールディング
複数のエントリーポイント（REST + CLI + MQ + gRPC）	Hexagonal	アダプターパターンで複数のエントリーポイントに対応できます
厳密なモジュールの物理的分離が必要な大規模企業	Clean	Entity → UseCase → Adapter の分離を徹底できます
インフラストラクチャ（DB、MQ など）の変更が頻繁	Hexagonal または Onion	Port/Adapter により簡単に切り替えられます
迅速なプロトタイプ作成から、後で DDD に移行	Layered → アップグレード	導入コストが最小限で、明確な進化の道筋があります
複雑なビジネスルール + TDD	Hexagonal	ドメインレイヤーを独立してテストできます
DDD に不慣れなチームで、段階的な導入を目指す	Layered	従来の 3 層アーキテクチャに最も近く、学習曲線が最も緩やかです
マイクロサービスの内部アーキテクチャ標準	サービスごとに Hexagonal + COLA	ポートによる分離 + エンジニアリング標準
読み取りが多く、クエリが複雑	CQRS L2	読み取りと書き込みを分離し、個別に最適化できます
完全な監査証跡が必要	Event Sourcing（L3）	イベントストリームが監査を自然にサポートします

ドメインの分割とマイクロサービスへの分割

ドメインの分類（コア／汎用／支援）

ドメインの種類	投資戦略	推奨アーキテクチャ	例
Core Domain（コアドメイン）	最大限に投資し、内製する	リッチドメインモデルを備えた Hexagonal / Clean / COLA	注文管理、決済処理、価格設定エンジン
Generic Domain（汎用ドメイン）	購入するか、オープンソースを再利用する	Layered または既製の SaaS	認証、認可、通知
Supporting Domain（支援ドメイン）	外部委託するか、優先度を下げる	Layered またはシンプルな CRUD	レポート、管理ダッシュボード、データエクスポート

重要なルール：汎用ドメインや支援ドメインに Hexagonal や Clean を適用しないでください。労力が無駄になります。複雑なアーキテクチャはコアドメインだけに適用してください。

マイクロサービスの分割ルール

1. デフォルト：境界づけられたコンテキスト 1 つにつき、マイクロサービス 1 つ
2. 分割する条件：デプロイの頻度、スケーリングのニーズ、チームの所有権が異なる
3. 統合する条件：強いトランザクション整合性が必要、コンテキストが小さい（開発期間が 2 週間未満）、同じチームが担当
4. 保守的に始める：サービスの数を少なくし、必要に応じて分割する（先読みではなく、必要性が実証されてから）
5. 通信：結果整合性にはイベント、強い整合性には RPC（まれ）

CQRS レベルの提案

レベル	説明	コスト	アーキテクチャのサポート	使用するタイミング
L0 — なし	単一モデル、単一 DB	ゼロ	すべてのアーキテクチャ（デフォルト）	シンプルな CRUD、読み取りと書き込みの競合がない場合
L1 — モデル分離	CommandService + QueryService、共有 DB	低	すべてのアーキテクチャ	読み取りと書き込みの差が中程度の場合
L2 — DB 分離	Command DB + Read DB（ES／スレーブ）、イベントで同期	中	ヘキサゴナル／クリーン／COLA	読み取り量が多い場合、複雑なクエリがある場合
L3 — イベントソーシング	イベントストア + プロジェクション、すべてのイベントを再生	高	ヘキサゴナル／クリーン	監査証跡、時間軸クエリ、コンプライアンスが必要な場合

推奨：L0 から始め、より高いレベルが必要であることを実証してください。適切なポート分離のため、L2 以上はヘキサゴナルまたはクリーンアーキテクチャと併せてのみ採用してください。

アーキテクチャスキルの選択

選択したアーキテクチャ	次のスキル
レイヤード	ddd-architecture-layered（インストール：npx skills add full-stack-skills/ddd-skills --skill ddd-architecture-layered）
オニオン	ddd-architecture-onion（インストール：npx skills add full-stack-skills/ddd-skills --skill ddd-architecture-onion）
ヘキサゴナル	ddd-architecture-hexagonal（インストール：npx skills add full-stack-skills/ddd-skills --skill ddd-architecture-hexagonal）
クリーン	ddd-architecture-clean（インストール：npx skills add full-stack-skills/ddd-skills --skill ddd-architecture-clean）
COLA	ddd-architecture-cola（インストール：npx skills add full-stack-skills/ddd-skills --skill ddd-architecture-cola）

関連：ddd-cqrs-architecture ／ ddd-domain-designer ／ ddd-architecture-evaluator（いずれも npx skills add full-stack-skills/ddd-skills --skill <name> でインストールできます）

注意点

15 個の落とし穴については、references/gotchas.md を参照してください。

よくある質問

15 件の Q&A については、references/faq.md を参照してください。

セキュリティと安全性

このスキルは純粋なドキュメントです。ユーザーデータを収集せず、外部サービスやネットワークにアクセスせず、実行可能なスクリプトも含みません。

参考資料

詳細な比較、マイクロサービス／ドメイン、クリーン＋DDD＋ヘキサゴナル、ddd4j の分析、注意点、よくある質問、外部リソース、5 件のケーススタディについては、references/ を参照してください。