software-patterns

ソフトウェアパターン入門

概要

アーキテクチャパターンは、特定の構造上の問題を解決します。このスキルでは、各パターンをいつ適用するかを判断するためのフレームワークを提供します。覚えるべきパターンの一覧ではありません。

基本理念： パターンは問題を解決します。問題がなければ、パターンは必要ありません。

このスキルを使うタイミング

次の場合に有効にしてください：

• 新しいシステムや大規模な機能を設計するとき
• 外部サービスとの連携を追加するとき
• コードのテストや変更が難しくなったとき
• サービス同士が循環して呼び出し合うようになったとき
• あるコンポーネントの障害がほかのコンポーネントにも連鎖するとき
• ビジネスロジックが複数の場所に分散しているとき

パターンの階層

基礎（デフォルトで適用）

これらのパターンは、保守しやすいシステムの構造的な基盤となります。適用しない具体的な理由がない限り、適用してください。

パターン	解決する問題	適用する兆候
依存性注入	密結合、テストできないコード	クラスが依存関係を自らインスタンス化している
サービス指向アーキテクチャ	モノリシックなもつれ、不明瞭な境界	ビジネスロジックが分散し、明確な所有者がいない

DI の簡単な例 — 適用前と適用後：

# BEFORE: tight coupling, hard to test
class OrderService:
    def __init__(self):
        self.db = PostgresDatabase()       # concrete dependency
        self.mailer = SmtpMailer()         # concrete dependency

# AFTER: dependencies injected, easily testable
class OrderService:
    def __init__(self, db: Database, mailer: Mailer):
        self.db = db
        self.mailer = mailer
# In tests: OrderService(db=FakeDatabase(), mailer=FakeMailer())

状況に応じて適用（必要性が生じた場合）

これらのパターンは、特定の問題に対処します。先回りして適用しないでください。

パターン	解決する問題	適用する兆候
リポジトリ	データアクセスの結合	サービスがデータベースの詳細を把握している
ドメインイベント	循環依存、時間的結合	サービス A が B を呼び出し、B が C を呼び出し、C が A を呼び出している
腐敗防止層	外部システムとの結合	外部 API の変更でコードが壊れる
サーキットブレーカー	障害の連鎖	1 つの低速なサービスがすべてを停止させる

→ 基礎パターンの詳細 → 状況に応じたパターンの詳細

クイック判断ツリー

Is code hard to test?
├─ Yes → Apply Dependency Injection
└─ No → Continue

Is business logic scattered?
├─ Yes → Apply Service-Oriented Architecture
└─ No → Continue

Do services know database details?
├─ Yes → Apply Repository Pattern
└─ No → Continue

Do services call each other in cycles?
├─ Yes → Apply Domain Events
└─ No → Continue

Does external API change break your code?
├─ Yes → Apply Anti-Corruption Layer
└─ No → Continue

Does one slow service break everything?
├─ Yes → Apply Circuit Breaker
└─ No → Current patterns sufficient

→ 判断ツリーの全体

実装の優先順位

新しいシステムを始めるとき：

1. 最初に： DI コンテナー／パターンを確立する
2. 次に： サービス境界を定義する（SOA）
3. 3 番目に： データアクセスにリポジトリを追加する
4. その後： 問題が現れたら、状況に応じたパターンを重ねる

既存のシステムをリファクタリングするとき：

1. 最初に： 具体的な問題点を特定する
2. 次に： それを解決する最小限のパターンを適用する
3. 3 番目に： さらに追加する前に、改善を検証する

ナビゲーション

パターンの詳細

• 基礎パターン：DI と SOA の実装ガイド、適用を避けるべき場面
• 状況に応じたパターン：リポジトリ、ドメインイベント、ACL、サーキットブレーカーの詳細

判断のサポート

• 判断ツリー：パターン選択のための完全なフローチャート
• アンチパターン：よくある誤用とその見分け方
• コードのにおいの兆候：低レベルのコードのにおい（大きな switch 文、ネストしたループ、パラメーターの再代入、高い複雑度／結合度）を、それらが示すアーキテクチャ上の問題と、それぞれを解決するパターンに対応付けています。CAST Highlight の _multi 品質指標に基づいています（https://doc.casthighlight.com/）

実装

• 例：各パターンの組み合わせを示す、言語に依存しない擬似コード

危険信号 — STOP

次の場合は STOP してください：

• 「これらのパターンを最初からすべて追加しよう」→ 現在の問題を解決するものだけを適用してください
• 「このパターンはベストプラクティスだ」→ どの問題に対するベストプラクティスですか？
• 「後で必要になるかもしれない」→ YAGNI。必要になったら追加してください
• 「サービスロケーターのほうが簡単だ」→ 隠れた依存関係はテストを困難にします
• 「このサービスを直接呼び出せばいい」→ イベントを使えば、より疎結合になるか検討してください
• 「外部 API は安定しているので、ACL は必要ない」→ API はいずれ必ず変わります

これらはすべて、STOP を意味します。まず具体的な問題を特定してください。

他のスキルとの連携

• test-driven-development：DI によってテストが容易になり、TDD でパターンの適用を検証します
• systematic-debugging：明確な境界（SOA）によってデバッグが容易になります
• root-cause-tracing：適切に構造化されたサービスでは、呼び出しの連鎖がより明確になります

パターンの組み合わせ

一般的で効果的な組み合わせ：

シナリオ	パターン
新しいマイクロサービス	DI + SOA + Repository
外部 API との連携	DI + ACL + Circuit Breaker
イベント駆動型システム	DI + SOA + Domain Events
データ量の多いアプリケーション	DI + SOA + Repository + Unit of Work

---

覚えておいてください： パターンは問題を解決するためにあります。パターンではなく、問題から始めましょう。