domain-driven-design

ドメイン駆動設計

このスキルを使用する場面

• 明示的な境界を持つ複雑なビジネスドメインをモデリングする必要がある場合。
• 完全な DDD が追加の複雑さに見合う価値があるかどうかを判断したい場合。
• 戦略的設計の決定を実装パターンに結び付けたい場合。
• ドメインのニーズから CQRS、イベントソーシング、サーガ、プロジェクションを計画している場合。

このスキルを使用しない場面

• 問題がビジネス上の複雑さの低い単純な CRUD である場合。
• 局所的なバグ修正のみが必要な場合。
• ドメイン知識へのアクセスがなく、代理となるプロダクトエキスパートもいない場合。

手順

1. 完全な DDD に取り組む前に、実現可能性チェックを実行します。
2. まず戦略的成果物を作成します：サブドメイン、境界づけられたコンテキスト、言語用語集。
3. 現在のタスクに基づいて、専門スキルに振り分けます。
4. 各段階の成功基準と根拠を定義します。

実現可能性チェック

以下のうち少なくとも 2 つが当てはまる場合にのみ、完全な DDD を使用します：

• ビジネスルールが複雑である、または頻繁に変化する。
• 複数のチームがモデルの衝突を引き起こしている。
• 統合契約が不安定である。
• 監査可能性と明示的な不変条件が重要である。

ルーティングマップ

• 戦略的モデルと境界：@ddd-strategic-design
• コンテキスト間の統合と変換：@ddd-context-mapping
• 戦術的コードモデリング：@ddd-tactical-patterns
• 読み書きの分離：@cqrs-implementation
• 信頼できる唯一の情報源としてのイベント履歴：@event-sourcing-architect と @event-store-design
• 長時間実行されるワークフロー：@saga-orchestration
• 読み取りモデル：@projection-patterns
• 意思決定ログ：@architecture-decision-records

テンプレートが必要な場合は、references/ddd-deliverables.md を開いてください。

出力要件

常に以下を返します：

• スコープと前提条件
• 現在の段階（戦略的、戦術的、またはイベント駆動）
• 作成された明示的な成果物
• 未解決のリスクと次のステップの推奨

例

Use @domain-driven-design to assess if this billing platform should adopt full DDD.
Then route to the right next skill and list artifacts we must produce this week.

制限事項

• このスキルは、ドメインエキスパートとの直接のワークショップを置き換えるものではありません。
• フレームワーク固有のコード生成は提供しません。
• 単純なシステムを過剰に設計するための正当化として使用すべきではありません。