golang-ddd

Golang DDD

「過剰に設計せずに、この Go サービスを変更しやすくする」というタスクで、具体的な手法がまだ明確でない場合は、これをデフォルトの手動エントリーポイントとして使用します。

ルーティングワークフロー

1. まず、タスクを分類します。

• 主な問題がパッケージ構成、レイヤー境界、共有モデル、依存関係の方向、またはインポートサイクルである場合は、$golang-ddd-architecture から始めます。
• 主な問題がハンドラー、リポジトリ、または変更可能な構造体に隠れたビジネスルールである場合は、$golang-ddd-refactor から始めます。
• 主な問題が肥大化したアプリケーションサービス、CRUD 名、読み取りと書き込みの混在、またはハンドラー固有の依存関係の増大である場合は、$golang-ddd-cqrs から始めます。
• 主な問題が Terraform、CI、テスト戦略、サービス認証、または安全な内部運用である場合は、$golang-ddd-infrastructure から始めます。

2. タスクが複数のレイヤーにまたがる場合は、スキルを組み合わせます。

• アーキテクチャとドメインのリファクタリングは、問題のあるコードを立て直すリファクタリングで最もよく使われる組み合わせです。
• 書き込み側のビジネスロジックがすでに存在し、アプリケーション層が肥大化している場合は、ドメインのリファクタリングと CQRS を組み合わせます。
• CI またはデプロイ作業によって境界の欠如が明らかになった場合は、アーキテクチャとインフラストラクチャを組み合わせます。
• テスト、認証、またはデリバリーの制約をコード構造に合わせる必要がある場合は、他のスキルの後にインフラストラクチャを適用できます。

3. 複数のスキルが該当する場合は、次の順序をデフォルトとして使用します。

• 最初に $golang-ddd-architecture
• 次に $golang-ddd-refactor
• 続いて $golang-ddd-cqrs
• 最後に $golang-ddd-infrastructure

4. 解決策は適切な規模に保ちます。

• 単純な CRUD に CQRS を無理に適用しないでください。
• 現在の複雑さに必要な範囲を超えて、モデルやレイヤーを分割しないでください。
• コードをより安全に変更できるようにする、最小限の変更を優先してください。

手動で呼び出す際のヒント

• どの専門スキルが適切か判断できない場合は、golang-ddd を使用します。
• 問題がすでに明らかな場合は、専門スキルを直接使用します。
• 詳細な指定がなく、ドメイン指向の整理またはリファクタリングを求められた場合は、ここから始めます。

関連スキル

• $golang-ddd-architecture
• $golang-ddd-refactor
• $golang-ddd-cqrs
• $golang-ddd-infrastructure

成果物

• 使用する関連スキル、またはスキルの適用順序を明確に選択すること。
• 実際の複雑さに合った、対象範囲の明確な計画。
• 単純なサービスに対する過剰設計の回避。