はじめに

ソフトウェアアーキテクチャは単なる「コードの配置ルール」ではありません。
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はその延長であり、外から見てもビジネスが中心に見える構造 を目指す思想です。

まとめ

悪い構造 → コードが「フレームワーク用語」を叫んでいる
良い構造 → コードが「ビジネスの意図」を叫んでいる

良いアーキテクチャとは、「このシステムは何を解決するのか？」を構造そのものが語る ものです。