DRESS CODE TECH BLOG
📚

現場直送!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 のおいしいところだけ取り入れる」くらいがちょうどいい
という印象です。


DRESS CODE TECH BLOG
DRESS CODE TECH BLOG

Discussion