arch-identify

1行でまとめると

提示された問題にどのアーキテクチャスタイルや横断的パターンが適しているかを診断します。または、アーキテクチャレベルの回答が過剰な場合は、よりシンプルなDDD／デザインパターンのスキルへ案内します。

このスキルを使う場面

• 新規システムで、大枠のアーキテクチャスタイル（モノリス／マイクロサービス／イベント駆動／サーバーレス）を選ぶとき。
• 既存システムで、スケーラビリティ、統合、トランザクションの一貫性に関する課題があり、「どのパターンが適しているか」と尋ねられたとき。
• アーキテクチャレビューの観点から、「YではなくXを使うべきだったか」と検討するとき。

このスキルを使わない場面

• ドメインモデリングに関する質問 → ddd-design へ案内します。
• コードレベルのパターンに関する質問 → gof-identify へ案内します。
• Kotlin固有のパターンに関する質問 → kp-identify へ案内します。

主な内容

次の診断質問を、記載順に使って問題を整理します。

1. システム全体の大枠に関する問題ですか？

• まずはシンプルなデプロイと単一のコードベースから始める場合 → arch-layered を使い、モノリスを維持します。実際の分割点が見つかるまでは、マイクロサービスに移行しないでください。
• ドメインの中核をフレームワーク／データベース／I/Oから切り離し、それぞれを独立して変更できるようにする場合 → arch-hexagonal（ポートとアダプター）を使います。
• 疎結合のコンポーネントがイベントを介して非同期に通信する場合 → arch-event-driven を使います。
• それぞれがデータを所有し、ネットワーク経由で通信する、独立してデプロイ可能な単位が必要な場合 → arch-microservices を使います。ただし、まずこのスキルの「使わない場面」セクションを読んでください。このスタイルは最も過剰に適用されがちです。

2. サービス／集約間のデータ、トランザクション、一貫性に関する問題ですか？

• 読み込み負荷と書き込み負荷が大きく異なり、読み込みには非正規化ビューが必要な場合 → arch-cqrs を使います。
• 信頼できる情報源が「現在の状態」ではなく「何が起きたか」であり、完全な監査履歴や時間軸に沿ったクエリが必要な場合 → arch-event-sourcing を使います。CQRSと自然に組み合わせられますが、必須ではありません。
• 複数ステップのビジネストランザクションが複数のサービスにまたがり、分散トランザクションを利用できない場合 → arch-saga を使います。

3. サービス間の障害対応に関する問題ですか？

• 下流サービスの性能が低下、または障害が発生し、呼び出し元サービスが自身を保護しながら適切に復旧する必要がある場合 → arch-circuit-breaker を使います（バルクヘッドとリトライポリシーも扱います）。

4. レガシーシステムの進化に関する問題ですか？

• 書き換えができず、継続的にリリースしながらモノリスからマイクロサービスへ段階的に移行する場合 → arch-strangler-fig を使います。アンチコラプションレイヤーと組み合わせることもよくあります（ddd-context-mapping を参照）。

5. アーキテクチャの品質やガバナンスに関する問題ですか？

• コードの進化に伴い、アーキテクチャが健全な状態を保っているかを知りたい場合 → arch-fitness-functions を使います。
• 将来の保守担当者が理由を把握できるよう、アーキテクチャ上の決定を記録したい場合 → arch-adr を使います。
• コンポーネントレベルの設計規律（単一責任、依存関係の方向など）に関する場合 → arch-solid を使います。

6. どれにも当てはまりませんか？

• アーキテクチャレベルの回答は不要かもしれません。多くの場合、DDDのモデリング上の判断（ddd-design）、コードレベルのパターン（gof-identify）、あるいは「過剰設計を避けて、モノリスを維持する」ことで解決できます。

判断のヒューリスティクス

• 分散化する具体的な理由が見つかるまでは、まずモノリスを選びます。
• 依存関係の方向を変える具体的な理由が見つかるまでは、レイヤードアーキテクチャを選びます（依存関係の方向を変えるのがヘキサゴナルアーキテクチャです）。
• 分散化にはコストがかかり、機能が増えるわけではありません。マイクロサービス、サーガ、イベント駆動、CQRSはいずれも運用の複雑さを増やします。具体的な要件に基づいて導入を正当化してください。
• 「[尊敬されている企業]がそうしているから、この方法で構築する」は理由になりません。

アンチパターン

• 先にマイクロサービスを選び、後からドメインモデルを無理に組み込むこと。データ結合が発生し、サービス間の呼び出しが増える原因になります。
• 実際には読み書きの非対称性がないのに、「高度に聞こえるから」という理由でCQRSを採用すること。不要なオーバーヘッドが生じます。
• 単一のトランザクション境界で済むのにサーガを採用すること。補償アクションには実際のエンジニアリングコストがかかります。
• 「履歴書のための開発」。適合性ではなく、キャリア上のアピールを理由にアーキテクチャを選ぶこと。

参照

• 13 個すべての arch-* パターンスキル。
• ddd-design と ddd-bounded-context — DDD は、多くの場合、パターンを選ぶ前にアーキテクチャレベルの意思決定に影響します。
• gof-identify — 問いがシステムレベルではなく、コードレベルの場合。

参考資料

• Richards & Ford, Fundamentals of Software Architecture（O'Reilly、2020年）— 第18章、適切なアーキテクチャスタイルの選択。
• Khononov, Learning Domain-Driven Design（O'Reilly、2021年）— 第14～15章、DDD ↔ マイクロサービス ↔ イベント駆動。