なぜクリーンアーキテクチャはドメインを守るのか

なぜクリーンアーキテクチャはドメインを守るのか

クリーンアーキテクチャはドメインを守っているが、その本質は「判断」を守ることである

はじめに

「クリーンアーキテクチャでは、ドメインを守ることが重要だ」

この説明を、これまで何度も目にしてきましたし、自分でも何となく理解しているつもりでした。

UI から独立させるため
フレームワークに依存させないため
テストしやすくするため

どれも間違ってはいません。

ただ、実務で設計に向き合えば向き合うほど、

それで結局、何が一番大事なのか？

という疑問が残りました。

最近、その答えが少しはっきりしてきました。

クリーンアーキテクチャの本質は、

「判断をどこに閉じ込めるか？」を決める構造である

という考え方です。

どの判断は UI に任せてよいのか
どの判断はユースケースで行うべきか
どの判断は、絶対に外に漏らしてはいけないのか

この「判断の置き場所」を曖昧にしたまま設計すると、

責務が混ざり
修正のたびに迷いが生まれ
変更に弱い構造

になっていきます。

では、

絶対に外に出してはいけない判断とは何なのか？

その答えを整理するための言葉が、不変条件 でした。

（不変条件という言葉は、英語では invariant という言葉でよく使用されます）

この記事では、

クリーンアーキテクチャを「判断の置き場所」という視点で捉え直し
その中で不変条件がどんな役割を持つのか
なぜ不変条件をドメインに閉じ込めるのか

を、実務の感覚に近い形で説明します。

不変条件とは何か

不変条件とは、

どれだけ仕様や実装が変わっても、絶対に破ってはいけない前提

です。

UI が変わっても API が変わっても DB が変わっても

これが壊れたら、そのシステムは成立しない

そういう条件を指します。

例

ログインしていないユーザーは、保護された操作をできない
残高は常に 0 以上である
同じ支払いは二重に確定しない

これらは

画面の都合でも
通信の都合でもなく

ビジネスやドメインとして「そうでなければならない」条件 です。

不変条件は「判断」そのものである

不変条件を別の言い方で表すと、こう言えます。

不変条件 = 揺れてはいけない判断

開発では、常に判断が発生します。

どこでチェックするか
どの層に責務を持たせるか
どこまでを UI に任せるか

その中には

仕様変更で変わってよい判断
絶対に変えてはいけない判断

が混ざっています。

この 変えてはいけない判断 を明確に言語化したものが、不変条件です。

不変条件が曖昧だと、設計は壊れる

不変条件が定義されていないと、次のようなことが起きます。

ある画面ではチェックしているが、別の画面では忘れている
API 側では弾いているが、ローカルでは通ってしまう
バグが出るたびに「どこで直すか」を毎回悩む

これは技術力の問題ではありません。

判断を置く場所が決まっていない ことが原因です。

結果として、

責務が混ざる
修正が各所に散在する
変更に弱い構造になる

という状態に陥ります。

不変条件をドメインに閉じ込める、という判断

ここで、クリーンアーキテクチャの話に戻ります。

クリーンアーキテクチャが「ドメインを守る」理由は、

不変条件を、最も外部影響の少ない場所に閉じ込めたい

からです。

なぜドメインなのか

ドメイン層は、

UI を知らない
フレームワークを知らない
通信や保存方法を知らない

つまり、

最も変わりにくい層 です。

そこに、

残高チェック
状態遷移の正当性
ビジネスルール

といった 不変条件を集約する。

これは

この判断は、ここでしか行わない

と決める行為そのものです。

「ドメインを守る」とは、何を守っているのか

よくある説明では、

ドメインを UI から守る
ドメインをフレームワークから守る

と言われます。

しかし、本質は少し違います。

守っているのは、ドメインではなく「判断」 です。

ここで必ずチェックする
ここで必ず保証する
ここでは絶対に例外を許さない

という判断を、

仕様変更
実装都合
短期的な修正

から守っている。

それが結果として「ドメインを守っている」ように見えるだけです。

UI やインフラに不変条件を置くと何が起きるか

不変条件を

UI
ViewModel
Controller

に置くと、どうなるでしょうか。

画面が増えるたびに同じ判断が必要になる
実装漏れが起きる
「この画面だけ例外」が増える

不変条件は、本来

考えなくていいようにするためのもの

なのに、

毎回考え直す対象 になってしまいます。

まとめ

不変条件とは、揺れてはいけない判断である
設計とは、判断を置く場所を決める行為である
クリーンアーキテクチャは、不変条件をドメインに閉じ込めるための構造である
「ドメインを守る」とは、「判断を守る」ことに他ならない

クリーンアーキテクチャを

難しいもの
大げさなもの

と感じている場合、

一度 不変条件という言葉 で捉え直してみてください。

「なぜここにロジックを置くのか」「なぜここに依存させないのか」

その理由が、かなりクリアになるはずです。

この記事が、

設計に違和感を感じている人
クリーンアーキテクチャにモヤっとしている人

の視点整理の助けになれば嬉しいです。

なぜクリーンアーキテクチャはドメインを守るのか#

はじめに#

不変条件とは何か#

例#

不変条件は「判断」そのものである#

不変条件が曖昧だと、設計は壊れる#

不変条件をドメインに閉じ込める、という判断#

なぜドメインなのか#

「ドメインを守る」とは、何を守っているのか#

UI やインフラに不変条件を置くと何が起きるか#

まとめ#

おすすめの関連書籍（無料）#