現場直送!Clean Architecture を導入して分かったメリットと注意点!
📘 Clean Architecture を導入してみて感じたこと
Dress Code Advent Calendar 2025 の 22 日目の記事です。
業務で Clean Architecture を部分導入してみたので、2〜3年ほど実際に触ってみました。
結果として、
- 「ここは良くなった!」と思う部分
- 「思ったほど効果出なかったな…」と感じた部分
- 「これは導入あるあるだな」って問題
が色々と見えてきたので、現場のリアル目線でまとめます。
♻️ 要約

🧩 Clean Architecture のざっくり図
CA をとても雑に図にするとだいたいこんな感じ。
基本的には、外側の変更が内側(特に Domain)に影響しないようにする構造。
理論としては「堅牢で綺麗に保てる」っていう魅力があります。
🎯 導入してみた背景
CA を取り入れてみた理由はこんな感じ。
- 機能が増えてきてコードの置き場所があいまい
- 変更の影響範囲を把握しづらい
- UI とロジックが密結合でテストがしんどい
この辺りを改善したくて「部分導入してみよう」という判断になりました。
✅ 実際に良かったこと
● 責務の分離はやっぱり分かりやすい
「ロジックは UseCase」「ビジネスルールは Domain」「外部APIやDB操作は Infra」というように責務が整理されるので、コードを読むときの迷いが減りました。
苦手だった自分以外が書いたコードを読み解く時間もかなり減ったと思います。
“どこに書くべきか?”で悩む時間が減るのは純粋に開発体験として良いポイント。
● テストしやすい構造になるのは本当
UI や Infrastructure をモック化して、
UseCase だけに絞ってテストできるのはシンプルにやりやすかった。
- 依存先を気にしなくていい
- 副作用を考えなくていい
- テストが高速
という三拍子が揃うので、ここはメリットを強く感じました。
また、最近ではAIを利用したテスト作成も行なっていますが、依存先をモック化できることでAIによるテスト作成のしやすさもGoodなポイント。
❓ 一般的に言われる「変更に強い」は…正直実感薄かった
CleanArchitecture の代表的なメリットとして
インフラが変わっても Domain は影響を受けない
という話がありますが、実務ベースでは そもそもその“変更”がほとんど来ません。
- DB が変わることなんて滅多にない
- 外部 API クライアントを頻繁に差し替えることも無い
- ストレージを丸ごと移行するケースも稀
- インフラ層は基本的に安定している
なので、“守られている”という設計思想は理解できるものの、
**「その恩恵を肌で感じるシーンが少ない」**というのが正直な感想です。
🌀 CA 導入の落とし穴:理解度の差で一気に崩壊する
個人的には、ここが CleanArchitecture 導入最大の難しさだと思っています。
● チームの理解度が揃っていないと構造が崩れる
CleanArchitecture はルールの多いアーキテクチャなので、
理解度がバラバラだと次のような問題が発生しやすいです。
- UseCase に UI ロジックが混入
- Domain に DB 操作が登場し始める
- DTO を作りすぎ問題
- レイヤー間の依存方向が逆転する
- 「それ Clean Architecture っぽいだけでは?」という構造になる
特に、“名前は知っているけど正解は分からない”状態のメンバーがいると混沌が生まれがち。
結果、当初の狙いとは逆に 複雑で読みにくいアーキテクチャ が出来上がることもあります。
● 揃えるためのドキュメント・レビューコストが高い
構造維持のために、次のような追加コストが発生します。
- レイヤーの責務定義のドキュメント作成
- 「ここに書くべき」「これはダメ」のレビュー
- 新メンバーへの CleanArchitecture の説明
- 用語の意味合わせ(Domain / UseCase / Infra etc.)
このあたりが地味に重く、導入後しばらくは負荷が増える印象がありました。
❌ その他の苦労ポイント
● 小〜中規模だと過剰になりがち
「この機能をこの階層まで分ける必要ある?」という状況が出てきます。
● ディレクトリ構成に正解がない
CleanArchitecture は「流派」が多いので、以下の議論が長引きがち。
- UseCase の粒度
- DTO の置き場所
- ファイル分割のレベル
- Domain の切り方
整理しないまま進むと余計に混乱します。
📝 まとめ:CleanArchitecture は部分採用くらいが現実的
ざっくりまとめると、
- 責務整理とテストしやすさは強いメリット
- “変更に強い”メリットは現場だと実感しづらい
- 理解度の差があると崩壊しやすい
- 小〜中規模にはやや過剰
という結論になりました。
個人的には、
「CleanArchitecture のおいしいところだけ取り入れる」くらいがちょうどいい
という印象です。
Discussion