はじめに
ソフトウェアアーキテクチャは単なる「コードの配置ルール」ではありません。
Robert C. Martin（Uncle Bob）は「良いアーキテクチャは意図を叫ぶ（Screaming）」と述べています。
つまり、プロジェクトのディレクトリ構造や依存関係を見ただけで、
「このシステムは何をするものなのか」 が明確に分かるべきだ、という考え方です。
1. 悪い例：フレームワークが叫ぶ
典型的なWebアプリのプロジェクトを見てみましょう。
src/
├── controllers/
├── models/
├── views/
├── services/
└── repositories/
一見きれいに見えますが、これでは フレームワークの用語（MVC） が前面に出てしまい、
「このシステムが何をするのか」が伝わりません。
これでは「フレームワークが叫んでいる」状態です。
2. 良い例：ドメインが叫ぶ
では、アーキテクチャが「ビジネスの意図」を叫ぶように構造を変えるとどうなるでしょうか。
src/
├── orders/
│ ├── domain/
│ ├── usecase/
│ └── infra/
├── payments/
│ ├── domain/
│ ├── usecase/
│ └── infra/
├── inventory/
│ ├── domain/
│ ├── usecase/
│ └── infra/
└── shared/
これを見るだけで、
- このシステムは「注文」「支払い」「在庫」を扱う
- ビジネスロジックが中心にある
ことが明確に伝わります。
これが「アーキテクチャが叫んでいる」状態です。
3. Screaming Architecture の狙い
-
ビジネスを第一に表現
- 技術用語ではなく、ドメイン用語が構造に現れる
-
意図が伝わる構造
- 新しい開発者が見ても「このシステムは何をするか」がわかる
-
フレームワークに依存しない
- 技術スタックが変わってもアーキテクチャの骨格は変わらない
4. Clean Architectureとの関係
Clean Architectureでは「ビジネスルールを内側に、技術詳細を外側に置く」ことを強調しています。
Screaming Architectureはその延長であり、外から見てもビジネスが中心に見える構造 を目指す思想です。
まとめ
- 悪い構造 → コードが「フレームワーク用語」を叫んでいる
- 良い構造 → コードが「ビジネスの意図」を叫んでいる
良いアーキテクチャとは、「このシステムは何を解決するのか？」を構造そのものが語る ものです。