golang-ddd-cqrs

Golang DDD CQRS

Go コードを儀式的で重厚なエンタープライズ向けの足場にすることなく、アプリケーションロジックを明確なコマンドとクエリに分割するには、このスキルを使用します。

まずはこちら

• サービスに重要な書き込み側の処理がある場合、読み取りモデルと書き込みモデルが混在している場合、またはアプリケーションサービスの動作を把握しにくい場合は、CQRS を使用します。
• サービスの大半が単純な CRUD や、ビジネスロジックの少ないログインのようなフローである場合は、CQRS を使わないか、最小限にとどめます。

ワークフロー

1. ユースケースを書き込みと読み取りに分割します。

• コマンドは状態を変更し、エラーを返すことがあります。
• クエリはデータを返し、ビジネス上の状態変更を行ってはなりません。

2. ビジネスの用語で名前を付けます。

• ScheduleTraining、CancelTraining、ApproveReschedule、AvailableHours などを優先します。
• ビジネスで実際にそのように呼ぶ場合を除き、既定の CRUD 名は避けます。

3. 明確さが向上する場合は、ハンドラーを分けます。

• ロジックや依存関係が異なるコマンドごとに、コマンドハンドラー型を 1 つ用意します。
• 読み取り上の関心事が異なるクエリごとに、クエリハンドラー型を 1 つ用意します。
• インターフェースは小さく保ち、それを使用するハンドラーが所有するようにします。

4. ハンドラーはオーケストレーションのみに専念させます。

• ドメインルールはドメイン層に置きます。
• トランスポートのマッピングはポートに置きます。
• データベースや外部 API の詳細はアダプターに置きます。

5. CQRS に合わせてポートを設計します。

• HTTP または gRPC のポートからコマンドを直接呼び出せます。
• 作成コマンドの後に読み取りが必要な場合は、可能であれば 204 No Content と content-location を使用するか、コマンドの後に明示的なクエリを実行します。
• ポート固有のエラー変換は境界部分にとどめます。

6. アプリケーション層はオーケストレーションとしてテストします。

• リポジトリーと外部サービスは、小規模な手書きのモックで置き換えます。
• 挙動が本当にアプリケーションのオーケストレーションに属する場合を除き、ビジネスシナリオのアサーションはドメインテストに含めます。

ガードレール

• サービスがまだ単純な場合は、コマンドとクエリのパッケージを分けないでください。
• コマンドから、既定で大規模な読み取りモデルを返さないでください。
• 便利だからといって、コマンドハンドラーにビジネスロジックを隠さないでください。
• ハンドラーを分けることでインターフェースやテストが簡潔になる場合は、巨大なアプリケーションサービスを 1 つのままにしないでください。

次のリファレンスを参照してください

• 命名、パッケージ構成、トレードオフについては、references/cqrs-guidelines.md を参照してください。
• ハンドラーのテストとトランスポートに依存しないエラーについては、references/application-tests-and-errors.md を参照してください。

成果物

• ユースケースに合致したコマンドとクエリの境界。
• ビジネスを中心とした名前。
• ハンドラーが所有する小さなインターフェース。
• 薄いトランスポートコード。
• ドメインの内部実装ではなく、オーケストレーションに焦点を当てたハンドラーテスト。