ddd-architecture-awesome

DDD アーキテクチャのすべて

DDD スキルエコシステムのエントリーポイントです。このスキルでは、DDD を理解し、プロジェクトに適しているかを判断して、学習の道筋を立てるために必要なすべてを、ひとつにまとめて提供します。

使う場合と使わない場合

✅ 使う場合	❌ 使わない場合
多くのルールを持つ複雑なビジネスドメイン	ビジネスルールがほとんどないシンプルな CRUD
長期間運用するシステム（数年間の保守）	プロトタイプ、MVP、使い捨てのコード
開発者が 5 人以上のチーム	個人開発者、または小規模チーム（1～2 人）
複数のエントリーポイント（API、CLI、イベント）	単一のエントリーポイント、シンプルな API
インフラ（DB、ブローカー）を切り替える必要がある	インフラが固定されており、変更の可能性が低い
高いテストカバレッジが求められる	簡単なスクリプト、内部ツール
中国企業向けの Spring Boot + MyBatis スタック	すでに定着しており、適切に機能するアーキテクチャを採用している

まずはシンプルに始めましょう。複雑さを加えるのは、必要になってからです。 ほとんどのシステムには、完全な CQRS やイベントソーシングは必要ありません。

このスキルを使うタイミング

ユーザーが次の内容に言及した場合は、必ずこのスキルを使ってください。

• 「DDD とは何か」「DDD を説明して」「DDD 是什么」「介绍一下 DDD」
• 「ドメイン駆動設計」「领域驱动设计」
• 「DDD の基本」「DDD の基礎」「DDD 基础」「DDD 入门」
• 「DDD を使うべきか」「DDD の適用場面」「DDD 是否适合」
• 「DDD と CRUD の比較」「DDD と従来の手法の比較」「DDD 对比」
• 「DDD の概念」「DDD 概念」
• 「DDD の戦略的設計」「DDD の戦術的設計」「DDD 战略设计」「DDD 战术设计」
• 「DDD を適用するタイミング」「DDD が適切な場面」
• DDD のアーキテクチャの種類とその違いについての質問
• DDD を始めたばかりで、どこから始めればよいかを知りたい場合

---

1. DDD の定義

ドメイン駆動設計とは、複雑なビジネスルールをドメインモデルに取り込む開発手法です。まずビジネスの境界を定義し（戦略的設計）、次にルールをモデルに組み込みます（戦術的設計）。

重要な考え方：DDD はテクノロジーに関するものではなく、コードをビジネスの思考方法に合わせることです。

---

2. DDD の適用可否を判断するツリー

次の観点から評価し、「適している／慎重に検討／推奨しない」という結論を示してください。

観点	適している（✓）	慎重に検討（~）	推奨しない（✗）
ビジネスの複雑さ	複雑なルール、状態機械、チーム間の連携	いくつかのビジネスルールがあるが、ほとんどはシンプル	純粋な CRUD、データ入力
ライフサイクル	長期間運用し、継続的に進化する	中期的な運用で、ある程度の反復がある	短期間の運用、使い捨て
チームの成熟度	専任のドメインエキスパートがいて、PM が安定している	一般的なビジネス知識がある	ドメイン知識がない
エンジニアリング能力	テスト／可観測性が充実し、イベント駆動に対応できる	基本的な CI/CD と、ある程度のテストがある	テスト基盤がない

判断フローチャート

Is business logic complex (rules, state machines, constraints)?
├── NO → Is system long-lived (> 2 years)?
│         ├── NO → ✗ DDD NOT RECOMMENDED (Use simple CRUD + Service)
│         └── YES → ~ Cautious: adopt tactical patterns selectively
│
└── YES → Is there a domain expert or stable product owner?
          ├── NO → ~ Cautious: DDD without domain expert = complex code for nothing
          └── YES → Is the team familiar with DDD or willing to learn?
                    ├── NO → ~ Cautious: start with Layered, evolve later
                    └── YES → Do you need to swap infrastructure (DB, MQ)?
                              ├── NO → ✓ DDD RECOMMENDED (COLA or Layered)
                              └── YES → ✓ DDD STRONGLY RECOMMENDED (Hexagonal/Clean)

---

3. 複雑さの段階 — 段階を飛ばさない

各段階で実際に複雑さが増します。現在の段階では不十分だと確認できた場合にのみ、次の段階へ進んでください。

Level 1: Simple Layered (Controller → Service → Repository)
   ↓ When business rules grow complex and need explicit modeling
Level 2: DDD 4-Layer with Rich Domain Model (Layered)
   ↓ When need multiple entry points (REST + CLI + MQ + gRPC)
Level 3: Ports & Adapters (Hexagonal Architecture)
   ↓ When read/write patterns diverge significantly
Level 4: CQRS — Separate Read/Write Models
   ↓ When need complete audit trail / temporal queries
Level 5: Event Sourcing — Store events, derive state

Your project Level: ___ (Recommend with reasoning)

---

4. パターンの境界 — 各パターンとは何か、何ではないか

この表では、DDD で最もよくある混乱を解消します。「これらのパターンの違いは何か、どのような場合にそれぞれを使うべきか？」

パターン	主な問い	用途	次のように捉えてはいけないもの
DDD	複雑なビジネスドメインをどのようにモデル化するか？	ユビキタス言語、境界づけられたコンテキスト、集約、値オブジェクト	それだけで成り立つフォルダー構成
ヘキサゴナルアーキテクチャ	アプリケーションは外部の世界とどのようにやり取りするか？	ポート、ドライバーアダプター、ドリブンアダプター、テスト可能なアプリケーションコア	6 つの辺や、特定の 1 つのパッケージ構成を義務づけるもの
クリーンアーキテクチャ	依存関係はどの方向を向くべきか？	内向きの依存関係ルール、ユースケースの境界、フレームワークからの独立性	万能な 4 フォルダーのテンプレート
オニオンアーキテクチャ	ドメインモデルをどのように中心に保つか？	ドメイン中心のレイヤーと依存関係逆転	クリーンアーキテクチャやヘキサゴナルアーキテクチャですでに解決できる問題に対する別個の要件
COLA v5	エンタープライズ Java チームで DDD をどのように標準化するか？	ダイヤモンドアーキテクチャ、スキャフォールディング、自動アーキテクチャ検証	あらゆるプロジェクトに通用する万能策
レイヤードアーキテクチャ	DDD をどのように段階的に導入するか？	4 層の分離、既存の 3 層プロジェクトへの最小限の影響	恒久的な到達点（準備が整ったら進化させます）
CQRS	読み取りと書き込みに異なるモデルが必要か？	読み取りと書き込みのワークロードが異なる境界づけられたコンテキスト	デフォルトのアプリケーションアーキテクチャ
イベントソーシング	完全なイベント履歴から状態を復元する必要があるか？	監査証跡、時間軸に沿ったクエリ、再生可能なワークフロー	CRUD システムのデフォルトの永続化方式

---

5. DDD アーキテクチャの全体像

DDD Architecture Family:

  Foundational (Learning cost: Low → Medium):
  ├── Layered Architecture (分层架构)
  │   └── Classic 4-layer: Interface → Application → Domain ← Infrastructure
  │       1-5 people | CRUD-friendly | Spring Boot native
  │
  ├── Onion Architecture (洋葱架构)
  │   └── Domain core, concentric dependency rings, inner defines interface
  │       5-15 people | High testability | Frequent infra changes
  │
  ├── Hexagonal Architecture (六边形架构 / Ports & Adapters)
  │   └── Domain at center, ports define contracts, adapters implement
  │       5-15 people | Multi-entry systems | Best testability
  │
  Advanced (Learning cost: Medium → High):
  ├── Clean Architecture (整洁架构)
  │   └── Entities → Use Cases → Interface Adapters → Frameworks
  │       15-50 people | Enterprise systems | Strict module isolation
  │
  └── COLA Architecture (COLA v5 架构)
      └── Diamond pattern: Adapter → App → Domain ← Infrastructure
          5-50 people | Chinese enterprise | Best tooling & community

  Complementary Patterns:
  ├── CQRS — Separate read/write models (L1: Model only / L2: DB separation / L3: Event Sourcing)
  ├── Domain Events — Cross-aggregate eventual consistency
  └── Event Sourcing — Store events as source of truth

アーキテクチャの視覚的な比較

Layered        Onion        Hexagonal      Clean          COLA v5
┌────────┐   ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐
│Interf. │   │ Infra    │  │ Adapter  │  │ Frame.   │  │ Adapter  │
├────────┤   │ ┌──────┐ │  ├──────────┤  ├──────────┤  ├──────────┤
│  App   │   │ │ App  │ │  │  Ports   │  │ Adapter  │  │   App    │
├────────┤   │ │┌────┐│ │  ├──────────┤  ├──────────┤  ├──────────┤
│ Domain │   │ ││Dom.││ │  │ Domain ★ │  │ Domain ★ │  │ Domain ★ │
├────────┤   │ ││ ★  ││ │  └──────────┘  └──────────┘  ├──────────┤
│ Infra  │   │ │└────┘│ │                              │ Infra    │
└────────┘   │ └──────┘ │                              └──────────┘
             └──────────┘

---

6. DDD の主要概念クイックリファレンス

6.1 戦略的設計（战略设计）

概念	定義	要点
境界づけられたコンテキスト	ドメインモデルの整合性が保たれる境界	各コンテキストには独自のユビキタス言語があります
ユビキタス言語	開発者とドメインエキスパートが共有する言語	コード、会話、ドキュメントで使用されます
コンテキストマッピング	境界づけられたコンテキスト間の関係	パートナーシップ、共有カーネル、顧客と供給者、ACL、OHS
コアドメイン	ビジネスで最も重要な部分	ここに最も多くの労力を投入します
サブドメイン	ビジネスを支援する機能または汎用的な機能	コア／支援／汎用

6.2 戦術的設計（战术设计）

パターン	目的	主要なルール
エンティティ	永続する識別子を持つオブジェクト	等価性は属性ではなく ID で判定します
値オブジェクト	属性によって定義される不変のデータ	値で等価性を判定し、セッターはありません
集約	整合性を保つ境界	1 つの集約につき 1 つのトランザクション
集約ルート	集約への唯一のエントリーポイント	外部から参照できるのはルートのみです
リポジトリ	永続化の抽象化	集約ごとに 1 つのリポジトリ
ドメインサービス	ステートレスなエンティティ間ロジック	どのエンティティにも適合しないロジックに使用します
ドメインイベント	意味のある変更の記録	過去形の命名（OrderPaid）
ファクトリー	複雑なオブジェクトの生成	コンストラクターだけでは不十分な場合に使用します
仕様	組み合わせ可能なビジネスルール	AND／OR／NOT を組み合わせられます

6.3 簡易判断ツリー

「このコードはどこに置くべきか？」

Where does this code go?
├─ Pure business logic, no I/O           → domain/
├─ Orchestrates domain + has side effects → application/
├─ Talks to external systems              → infrastructure/
├─ Defines HOW to interact (interface)    → port (domain or application)
└─ Implements a port                      → adapter (infrastructure)

「エンティティか、値オブジェクトか？」

Entity or Value Object?
├─ Has unique identity that persists → Entity
├─ Defined only by its attributes    → Value Object
├─ "Is this THE same thing?"         → Entity (identity comparison)
└─ "Does this have the same value?"  → Value Object (structural equality)

「これを独自の集約にするべきか？」

Aggregate boundaries?
├─ Must be consistent together in a transaction → Same aggregate
├─ Can be eventually consistent                 → Separate aggregates
├─ Referenced by ID only                        → Separate aggregates
└─ >10 entities in aggregate                    → Split it

ルール： 1 つのトランザクションにつき 1 つの集約です。集約をまたぐ整合性は、ドメインイベント（結果整合性）によって保ちます。

---

7. リッチドメインモデルと貧血 CRUD の違い（重要な区別）

// ❌ Anemic Model (Anti-Pattern) — Data bag + Service
@Entity
public class Order {
    private Long id;
    private String status;       // String instead of Value Object
    // Only getters/setters, NO behavior
}

@Service
public class OrderService {       // God Service with all logic
    @Transactional
    public void pay(Long orderId) {
        Order order = orderRepo.findById(orderId);
        if ("DRAFT".equals(order.getStatus())) {  // Raw string comparison
            order.setStatus("PAID");
            orderRepo.save(order);
        }
    }
}

// ✅ Rich Domain Model (DDD) — Behavior WITH data
public class Order extends AggregateRoot<OrderId> {
    private OrderStatus status;      // Value Object
    private Money totalAmount;
    private List<OrderItem> items;

    public void pay() {              // Behavior in entity
        if (!status.canPay()) {
            throw new OrderException("Cannot pay in current status");
        }
        this.status = OrderStatus.PAID;
        addDomainEvent(new OrderPaidEvent(this.id));
    }
}

集約のサイズに関するヒューリスティック

指標	健全	警告	対応
集約あたりのエンティティ数	1-5	6-10	>10：分割
行数（ルート）	<500	500-1000	>1000：分割
トランザクションのロック時間	<100ms	100-500ms	>500ms：分割
同時変更の競合	まれ	ときどき	頻発：分割

---

8. アンチパターン（重大 — 修正方法付き）

アンチパターン	問題	修正方法
貧血ドメインモデル	エンティティがデータの入れ物になり、ロジックがサービスに置かれています	振る舞いをエンティティ内に移します
テーブルごとのリポジトリ	集約の境界が崩れます	集約ごとに1つのリポジトリを設けます
インフラストラクチャの漏出	ドメインがDB／HTTPライブラリをインポートしています	ドメインには外部依存関係を一切持たせません
巨大な集約	エンティティが多すぎて、トランザクションが遅くなります	より小さな集約に分割します
ユースケースの省略	コントローラーがリポジトリを直接呼び出します	アプリケーションのユースケースを経由させます
CRUD思考	振る舞いではなく、データをモデル化しています	ビジネスオペレーションをモデル化します
時期尚早なCQRS	必要になる前に複雑さを加えています	シンプルに始め、段階的に発展させます
集約をまたぐTX	1つのトランザクションに複数の集約が含まれています	整合性にはドメインイベントを使用します
ドメインエキスパートなしのDDD	ビジネスへの理解なしにアーキテクチャを構築しています	エキスパートなしのDDDは、複雑なコードにつながります
フレームワーク優先の考え方	ドメインを理解する前に技術を選んでいます	ドメインを先に、技術を後にします

---

9. 実装順序（共通）

1. Discover the Domain — Event Storming, conversations with domain experts
2. Model the Domain — Entities, value objects, aggregates (NO infrastructure)
3. Define Ports — Repository interfaces, external service interfaces
4. Implement Use Cases — Application services coordinating domain
5. Add Adapters LAST — HTTP, database, messaging implementations

DDD is collaborative. Modeling sessions with domain experts are as important as code patterns.

---

10. このスキルの使い方

ステップ1：ユーザーの状況を把握する

プロジェクトの性質、ビジネスの複雑さ、チーム構成、現状について質問します。

ステップ2：DDDの適用可能性を評価する

判断ツリー（セクション2）に沿って評価し、次のいずれかを提示します。

• 適している：アーキテクチャの選定に進みます
• 慎重に検討：選択的な導入を推奨します
• 推奨しない：理由を説明し、過剰な設計を防ぎます

ステップ3：学習パスを推奨する

ユーザータイプ	推奨パス
DDD初心者	awesome → selector → (architecture Skill) → code-reviewer
アーキテクト／テックリード	selector → (architecture Skill) → domain-designer → doc
DDDへの移行	awesome → selector → (architecture Skill) → reviewer → evaluator
レイヤード	selector → architecture-layered → domain-designer
オニオン	selector → architecture-onion → domain-designer
ヘキサゴナル	selector → architecture-hexagonal → domain-designer + api-designer
クリーン	selector → architecture-clean → domain-designer
COLA	selector → architecture-cola → domain-designer → api-designer
CQRSが必要	selector → cqrs-architecture（単独、またはアーキテクチャに組み込み）
マイクロサービス＋イベント	selector → (architecture Skill) → cqrs-architecture → api-designer
コードレビュー	code-reviewer（単独）
アーキテクチャ評価	evaluator（定期的に実施）
アーキテクチャ文書	doc（単独、既存コードを読み取ります）
イベントストーミングのワークショップ	event-storming（単独、またはdomain-designerと併用）
テスト戦略	testing-strategist（単独、またはarchitecture Skillと併用）
DevOps統合	devops-integration（CI/CDパイプラインと併用）

ステップ4：出力形式

回答は常に次の構成にします。

1. 適用可能性の評価 — 明確な結論と、各評価軸に基づく理由
2. DDDの主要概念の概要 — 状況に合わせた内容
3. 推奨学習パス — 使用するスキルとその順序

---

11. 参考資料

完全な出典一覧（原著／パターンの参考資料／実装ガイド／中国語リソース／各言語の参考実装）は、references/00-sources.mdを参照してください。必要に応じて読み込みます。

---

参考ライブラリ（必要に応じて読み込み）

このスキルには、学習パスごとに整理された構造化参考ライブラリが含まれています。各ファイルは、エージェントが必要性を判断した場合に限り、必要に応じて読み込まれます。

これらの参考資料の使い方

ユーザーから質問された場合は、以下から該当するカテゴリを探し、関連するファイルを読んでください。すべてのリファレンスを一度に読み込まないでください。

ユーザーの質問	読み込むファイル
「なぜDDDなのか？」「DDDを使うべきか？」「DDDとCRUDの比較」	references/01-strategic/01-why-ddd.md
「ドメイン／サブドメインとは？」「コア／汎用／支援の違い」	references/01-strategic/02-domain-and-subdomain.md
「境界づけられたコンテキストとは？」「境界づけられたコンテキストの分割方法」「コンテキストマッピング」	references/01-strategic/03-bounded-context.md
「エンティティと値オブジェクトの違い」「エンティティ／VOを使う場面」「等価性のパターン」	references/02-tactical/01-entity-and-value-object.md
「集約の設計方法」「集約設計の原則」「集約の境界」	references/02-tactical/02-aggregate-design.md
「詳細解説：集約設計のプロセス」「イベントストーミングから集約に至る5つのステップ」	references/02-tactical/03-aggregate-deep-dive.md
「ドメインイベントの解説」「イベントを使った疎結合の方法」「イベントバス、イベントソーシング」	references/02-tactical/04-domain-events.md
「DDDの構成要素」「命名規則」「集約サイズの指標」	references/02-tactical/05-building-blocks.md
「DDDの戦術的パターンをすべて解説」「リポジトリ、ファクトリー、仕様パターン」	references/02-tactical/06-tactical-concepts.md
「クリーンアーキテクチャの戦術的リファレンス（原典）」	references/02-tactical/07-clean-tactical-reference.md
「DDDアーキテクチャの比較」「どのアーキテクチャを選ぶべきか？」「レイヤード、ヘキサゴナル、クリーンの比較」	references/03-architecture/01-comparison.md
「自分のプロジェクトにDDDは適しているか？」「DDD適用可否の判断マトリクス」「実際のシナリオ」	references/03-architecture/02-decision-matrix.md
「DDDのレイヤードアーキテクチャの詳細」「4層の責務、厳格なレイヤー分割と緩やかなレイヤー分割」「3層アーキテクチャからDDDへの移行」	references/03-architecture/03-layered-architecture-detail.md
「アーキテクチャの詳細解説」「DDD＋ヘキサゴナル＋クリーン＋COLAの詳細解説」	references/03-architecture/04-architecture-deep-dive.md
「4層アーキテクチャのリファレンス」「ドメイン／アプリケーション／インフラストラクチャ／プレゼンテーションのコードテンプレート」	references/03-architecture/05-clean-layers-reference.md
「ヘキサゴナルアーキテクチャのリファレンス」「ポート＆アダプターのコード例」	references/03-architecture/06-clean-hexagonal-reference.md
「DDD戦略設計のリファレンス（原典）」「境界づけられたコンテキスト、コンテキストマッピング」	references/03-architecture/07-clean-strategic-reference.md
「クイックチートシート」「パターンの境界、レイヤーの概要、判断ツリー」	references/04-quick-ref/01-cheatsheet.md
「DDDマインドマップ — 知識体系の全体像」「戦略、戦術、アーキテクチャ、プロセス、原則、実装」	references/04-quick-ref/02-ddd-mindmap.md
「イベントストーミングのワークショップ手法」「6段階のワークショッププロセス、ファシリテーターガイド」「DDDの発見を進める方法」	references/05-implementation/01-event-storming-workshop.md
「ドメインからコードへのオブジェクトマッピング」「ドメインオブジェクトをコードオブジェクトにマッピングする方法」「マッピング表のテンプレート」	references/05-implementation/02-domain-to-code-mapping.md
「マイクロサービスのコードモデル構造」「ディレクトリ構成、パッケージ規約、レイヤードコード」	references/05-implementation/03-code-model-structure.md
「レイヤー間のサービスとデータの連携」「DO／DTO／VO／POの変換チェーン」「厳格なレイヤー分割におけるサービス呼び出し」	references/05-implementation/04-service-data-collaboration.md
「マイクロサービスの境界と進化」「論理／物理／コードの境界」「アーキテクチャを安全に進化させる方法」	references/05-implementation/05-boundaries-and-evolution.md
「DDDによるミドルプラットフォーム（中台）の設計」「プラットフォームとミドルプラットフォームの違い、モデリングの5ステップ」「トップダウンとボトムアップの戦略」	references/06-enterprise/01-middle-platform-design.md
「マイクロサービスの設計原則と戦略」「ストラングラーとリペアラーのパターン」「4つの設計原則」	references/06-enterprise/02-microservice-design-principles.md
「分散アーキテクチャのFAQ」「シャーディング、CDC、キャッシュ、BFF、マルチデータセンターに関する重要な10の質問」	references/06-enterprise/03-distributed-architecture-faq.md

エンドツーエンドの例

例とリファレンスは異なります。リファレンスでは概念と原則を説明し、例では実際のビジネスの状況に即した具体的なコードで適用方法を示します。ユーザーが現実的なシナリオに DDD を適用する例を見たい場合に、これらを読み込んでください。

ビジネスシナリオ	示す内容	読み込むタイミング
勤怠管理システム	イベントストーミング → 集約設計 → サービス特定 → コード構成という一連のワークフロー。一般的ではない集約の扱いも含みます。	「DDD の完全な例を見せて」「DDD をエンドツーエンドで説明して」「考勤 DDD 案例」
Eコマースの注文	注文の中核となるドメイン：Order／OrderItem を使った集約設計、値オブジェクト（Money、OrderStatus）、ドメインイベント、完全なレイヤー構成のコード。	「Eコマースの DDD の例」「注文集約の設計」「电商 DDD 案例」
保険契約	複雑な集約設計：エンティティと値オブジェクトの判断、不変条件の適用、エンティティ間のロジックを担うドメインサービス。	「保険の DDD の例」「複雑な集約の設計」「保险 DDD 案例」

原則：「どこにでも DDD を適用するのではなく、重要なところに適用しましょう。」

その後、ddd-architecture-selector を使って適切なアーキテクチャパターンを選び、ddd-domain-designer でドメインモデリングに進み、対象のアーキテクチャスキルで実装に取り組んでください。

---

注意点 — よくある落とし穴

• 「DDD ＝ COLA」という誤解：DDD は COLA フレームワークと同じではありません。COLA は Alibaba のエコシステムにおける導入方法の一つにすぎません。Layered、Onion、Hexagonal、Clean など、ほかにもさまざまなアーキテクチャを選べます。プロジェクトの実際のニーズに合わせて選択してください。
• 最初から CQRS ＋ Event Sourcing に取り組む：ほとんどのプロジェクトで Event Sourcing は不要です。完全な監査追跡とタイムトラベルクエリが本当に必要か、まず評価してください。最もシンプルなレイヤードアーキテクチャから始めましょう。
• DDD を特効薬と見なす：DDD は複雑なビジネスドメインに適していますが、単純な CRUD プロジェクトでは過剰設計になることがあります。判断の目安は、ビジネスルールが CRUD 操作より重要であること、ドメインエキスパートが参加すること、長期的な保守が必要であることです。
• 戦術的設計を戦略的設計より先に行う：境界づけられたコンテキストを分割せずに、Entity／ValueObject を直接記述することです。戦略的な境界のない戦術的設計は、コンテキストの混乱やモデルの衝突につながります。
• ドメインエキスパートの参加が不足している：DDD では、ドメインエキスパートの継続的な参加が必要です。開発者が自分のビジネス理解だけを頼りにモデルを作ると、成果物のモデルが実際のビジネスからかけ離れる可能性があります。

このスキルを使用しないケース

❌ スキップするケース	✅ 代わりに使うもの
すでに DDD を十分に理解している	architecture-selector に進む
アーキテクチャの比較だけが必要	architecture-selector（より迅速）
概念ではなく、すぐにコードが必要	アーキテクチャスキルを直接選ぶ
シンプルなプロトタイプを構築する	DDD は使わず、シンプルな Spring Boot MVC を使う
既存プロジェクトでアーキテクチャがすでに機能している	architecture-evaluator（DDD が必要か評価する）

セキュリティと安定性

• すべてのコード例と概念の説明は学習目的です。実際の認証情報や機密データは含まれていません。
• このスキルでは DDD の方法論とパターンを学べます。コードを実行したり、外部システムにアクセスしたり、プロジェクトファイルを変更したりすることはありません。
• DDD の境界づけられたコンテキストによる分離は、システムの各部分の間にセキュリティ境界を自然に形成します。
• 実行可能なスクリプトは同梱されていません。このスキルは学習とリファレンスのためのリソースです。

🧭 DDD スキルの道のり

📍 現在地：ddd-architecture-awesome — ステップ 1：DDD 入門と全体像

flowchart LR
    S1["⭐ Step 1<br/>awesome<br/>入门与全景"] --> S2["Step 2<br/>selector<br/>架构选型"]
    S2 --> S3A["Step 3<br/>layered<br/>分层架构"]
    S2 --> S3B["Step 3<br/>onion<br/>洋葱架构"]
    S2 --> S3C["Step 3<br/>hexagonal<br/>六边形架构"]
    S2 --> S3D["Step 3<br/>clean<br/>整洁架构"]
    S2 --> S3E["Step 3<br/>cola<br/>COLA v5"]
    S3A & S3B & S3C & S3D & S3E --> S4A["Step 4<br/>domain-designer<br/>领域建模"]
    S3A & S3B & S3C & S3D & S3E --> S4B["Step 4<br/>cqrs-architecture<br/>CQRS"]
    S3A & S3B & S3C & S3D & S3E --> S4C["Step 4<br/>api-designer<br/>API设计"]
    S4A & S4B & S4C --> S5["Step 5<br/>code-reviewer<br/>代码审查"]
    S5 --> S6A["Step 6<br/>event-storming<br/>事件风暴"]
    S5 --> S6B["Step 6<br/>testing-strategist<br/>测试策略"]
    S5 --> S6C["Step 6<br/>devops-integration<br/>DevOps"]
    S5 --> S6D["Step 6<br/>evaluator<br/>架构评估"]
    S6A & S6B & S6C & S6D --> S7["🏁 Step 7<br/>architecture-doc<br/>架构文档"]

    style S1 fill:#10b981,stroke:#059669,color:white,stroke-width:3px

← 前へ：DDD の道のりはここから始まります 🚀 → 次へ：ddd-architecture-selector スキルに引き継ぎます — プロジェクトに適したアーキテクチャパターンを選びます（インストール：npx skills add full-stack-skills/ddd-skills --skill ddd-architecture-selector）。 🔗 関連：ddd-domain-designer スキルに引き継ぎます — すぐにドメインモデリングを始めます（インストール：npx skills add full-stack-skills/ddd-skills --skill ddd-domain-designer） | ddd-event-storming スキル — まずイベントストーミングのワークショップを行います（インストール：npx skills add full-stack-skills/ddd-skills --skill ddd-event-storming）。 🏠 ホーム：ここが出発点です

💡 DDD に初めて触れる方は、Section 4 の Pattern Boundaries 表と Section 6 のコア概念クイックリファレンスを読んでから、selector に進んでアーキテクチャを選んでください。