clean-ddd-hexagonal

クリーンアーキテクチャ、DDD、ヘキサゴナルアーキテクチャ

これらの関連パターンを使って、具体的なドメインや依存関係の問題を解決します。これは特定の立場に基づく統合であり、必須のフォルダー構成ではありません。ユーザーからの明示的な指示は、このスキルのガイドラインより優先されます。

適用範囲を選ぶ

要求された振る舞い、既存のドメインモデル、現在の依存関係を起点にします。変更がタスクの一部でない限り、プロジェクトの言語とアーキテクチャを維持してください。シンプルな CRUD はシンプルなままで構いません。チームの規模、エンティティ数、ファイルの長さによって、DDD が適切かどうかが決まるわけではありません。

設計上の問い	関連するパターン
ビジネスを表す言語や一貫性のルールは何か？	DDD、境界づけられたコンテキスト、集約
ソースコードの依存関係はどちら向きにすべきか？	クリーンアーキテクチャ／オニオンアーキテクチャ
アプリケーションで異なるインターフェースやインフラストラクチャを使うにはどうすればよいか？	ヘキサゴナルアーキテクチャのポートとアダプター
読み取りと書き込みで異なるモデルが必要か？	CQRS
イベント履歴から状態を再構築する必要があるか？	イベントソーシング

ビジネス上の不変条件が不明な場合は、欠けている具体的なルールを特定し、そのルールに依存しない作業を進めます。ビジネスの振る舞いを勝手に決めたり、局所的な修正のために要件発見ワークショップを必須にしたりしないでください。

重要な境界を維持する

• ドメインの振る舞いを HTTP、永続化、メッセージングの実装から独立させます。オーケストレーションはアプリケーションのユースケースに、外部との入出力はアダプターに配置します。
• エンティティの同一性と値オブジェクトの等価性を分けてモデル化します。トランザクション上の不変条件と競合を基に集約境界を選びます。
• 集約内で完結するトランザクションを優先します。要件で複数の集約にまたがる原子性が必要な場合は、結果整合性にひそかに置き換えるのではなく、そのトレードオフを明示します。
• データベースの変更と外部イベントの配信を確実に一体化する必要がある場合は、アウトボックスを使います。
• CQRS、イベントソーシング、リポジトリーインターフェース、独立したプレゼンテーション用フォルダーは、タスク上の妥当性を根拠に選択してください。例にある命名やディレクトリーは、プロジェクトに合わせて調整します。

影響を受ける境界と、それを説明するトレードオフを含め、要求されたモデル、パッチ、またはレビューを提示します。変更した不変条件とアダプターの契約を、適切なレベルで検証してください。アーキテクチャに関する質問で、すべてのパターンを実装する必要はありません。

参考資料

コレクション全体ではなく、検討中の判断に必要な参考資料を読みます。

タスク	参考資料
レイヤーの配置、依存関係の方向、コンポジションルート	LAYERS.md
境界づけられたコンテキスト、ユビキタス言語、コンテキストマッピング	DDD-STRATEGIC.md
エンティティ、値オブジェクト、集約、リポジトリー	DDD-TACTICAL.md
ポート、駆動側／被駆動側アダプター、代替レイアウト	HEXAGONAL.md
CQRS、イベント、アウトボックス、サガ、イベントソーシング	CQRS-EVENTS.md
ドメイン、統合、アーキテクチャのテスト設計	TESTING.md
パターンと配置の簡潔な一覧	CHEATSHEET.md

主な基盤となる資料：DDD、ヘキサゴナルアーキテクチャ、クリーンアーキテクチャ。