golang-ddd-architecture

Go の DDD アーキテクチャ

このスキルを使って Go サービスを設計し、ビジネスロジックの拡大に伴っても変更、テスト、理解がしやすい状態を保ちます。

まず確認すること

• このパターンを採用するだけの複雑さがサービスにあるか確認します。
• 単純な CRUD や認証のフローで、読み取りと書き込みのデータ形状がほぼ同じであり、ビジネスルールも少ない場合は、設計を小さく保ちます。
• ハンドラーの if 文が増え続けている、モデルが複数の境界で再利用されている、依存関係のモック作成や整理が難しい場合は、ワークフロー全体を適用します。

ワークフロー

1. エントリーポイントとユースケースを洗い出します。

• HTTP ハンドラー、gRPC サービス、CLI コマンド、メッセージコンシューマー、スケジュール済みジョブから始めます。
• コードを移動する前に、サポートする操作をビジネス上の表現に書き換えます。

2. 境界マップを作成します。

• ports はインバウンドのトランスポートとシリアライズのみを担当します。
• app はユースケースをオーケストレーションします。
• domain はビジネスルールと不変条件を管理します。
• adapters はデータベース、キュー、外部 API、ファイル、その他のインフラストラクチャとやり取りします。

3. 依存関係の方向を徹底します。

• domain は自身の外部に依存しません。
• app は domain をインポートできますが、具体的なトランスポートやアダプターのパッケージはインポートしません。
• ports と adapters は内側のレイヤーをインポートできます。
• インポート循環は、すべてを単一のパッケージに平坦化するのではなく、インターフェースを内側に移動するか、責任を分割して解消します。

4. インターフェースを利用側の近くに配置します。

• 振る舞いを必要とするパッケージ内にインターフェースを定義します。
• インターフェースは小さく、ユースケース指向に保ちます。
• コンポジションルートから実装を注入します。

5. 変更理由が異なるモデルは分離します。

• 変更頻度が本当に同じでない限り、DB の行、API レスポンス、Pub/Sub のペイロード、ドメインの状態に同じ構造体を再利用しません。
• 結合を取り除けるなら、データの重複を許容します。DRY は通常、データより振る舞いに対して価値があります。

6. main はシンプルに保ちます。

• main をコンポジションルートとして使います。
• リポジトリ、クライアント、ハンドラー、設定をそこで組み立てます。
• ビジネスロジック、バリデーション、ワークフローの分岐をそこに隠しません。

7. コードベースを、着手前よりテストしやすい状態にします。

• ドメインルールはモックなしで単体テストできるようにします。
• アプリケーションのオーケストレーションは、小さな手書きのモックでテストできるようにします。
• アダプターの振る舞いはインテグレーションテストでカバーします。

これらのリファレンスを参照する

• レイヤーのルール、パッケージ構成、アンチパターンについては、references/architecture-rules.md を読みます。
• 命名、モデルの境界、共有構造体のトレードオフが課題となる場合は、references/naming-and-models.md を読みます。

成果物

• 明確なレイヤーマップまたはパッケージ計画
• インポート循環を回避するためのハックなしにコンパイルできる依存関係の方向
• コンポジションルートでのコンストラクターまたは組み立てポイント
• 明示的なモデル境界
• 一度の作業でシステムの絡まりを解消できない場合の、後続リファクタリングの短いバックログ