クリーン・アーキテクチャ（Clean Architecture）は聞いたことがあったのですが、最近スクリーミング・アーキテクチャ（Screaming Architecture）というものを知りました。
良い機会だと思ったので、今回理解できたことを記事としてまとめます。
Screaming Architecture の概要
ソフトウェア開発者のロバート・C・マーティン（通称「アンクル・ボブ」）が提唱した概念で、
フレームワークに重心を置くのではなく、アプリケーションに重心を置いた設計が特徴です。
Screaming Architecture について理解できたこと
- ドメインモデルとビジネスロジックがアプリケーションの中心だと考える
- 技術フレームワーク、ツール、その他の二次的な懸念事項に重点を置く従来のアーキテクチャとは対照的
- より広範な
Clean Architecture原則と一致することが多い - 小規模なプロジェクトや単純なアプリケーションでは、
Screaming Architectureを実装するのは過剰なことがある - フレームワークファーストのアプローチに慣れているチームにとっては、学習コストが高く内面化するには時間がかかる
- 長期プロジェクトでスケーラビリティと保守性を担保したいシステムの場合に採用を検討すると良い
- コードベースでシステムが何をするのかを理解しやすい
- ビジネスロジックは、外部の依存関係やフレームワークから分離されるので特定のフレームワークとの密結合を回避でき、フレームワークなどを変更するリアーキテクト時の負荷を軽減してくれる
建物の建築様式を見た時に看板がなくても、それが図書館なのか、学校なのか、それともオフィスなのか、すぐに見分けがつくと思います。
ソフトウェアアーキテクチャにも同じでアプリケーションのフォルダ構造と設計を見れば、それが何のためにあるのかがすぐに理解できる。
という参考資料の例えがわかりやすかったです。
フレームワーク中心のアーキテクチャの問題点
フレームワーク中心の構造だと MVC を使用して構成されることが見受けられます。
これは技術的役割を反映したもので、ビジネスロジックやドメインロジックがわかりづらい構造であるとされています。
システムが財務データ、ユーザー管理、コンテンツ作成のいずれを扱っているかについては何も分かりません。
フレームワークの罠
フレームワークの慣習に基づいて構築した場合、フレームワークに密接に結合してしまいます。
技術スタックを変更する場合、リファクタリングで大きな労力を必要とします。
フレームワークとライブラリはソフトウェア開発に不可欠ですが、ビジネスロジックの構造を規定するものではありません。
従来のアーキテクチャとスクリーミングアーキテクチャの対比
参考資料から抜粋したディレクトリ構造の例です。
/src
/controllers
OrderController.cs
/services
OrderService.cs
/repositories
OrderRepository.cs
/models
Order.cs
OrderItem.cs
前述の通りフレームワークを中心としたフォルダ構造からはドメインに関する情報は何も得られません。
eコマースシステム、それとも金融アプリケーションなのかはコードを深く掘り下げなければわかりづらいです。
/src
/orders
OrderController.cs
OrderService.cs
OrderRepository.cs
Order.cs
OrderItem.cs
/inventory
InventoryController.cs
InventoryService.cs
InventoryRepository.cs
InventoryItem.cs
システムが注文と在庫を処理することが理解できます。
将来的にドメイン（顧客、支払いなど）を追加する場合でも、アーキテクチャ内に専用の場所が確保できる。
まとめ
シンプルな Web アプリケーションでも複雑なエンタープライズシステムでも、Screaming Architecture を採用することで、中長期的に安定した開発ができる環境を構築できると感じました。
一方で、メンバー全員が理解できないとすぐに崩壊してしまう危険もあると思いました。
人が入れ変わったとしても文化として残る仕組みも導入時に検討する必要があると思いました。
参考記事