なぜクリーンアーキテクチャはドメインを守るのか
なぜクリーンアーキテクチャはドメインを守るのか はじめに 不変条件とは何か 例 不変条件は「判断」そのものである 不変条件が曖昧だと、設計は壊れる 不変条件をドメインに閉じ込める、という判断 なぜドメインなのか 「ドメインを守る」とは、何を守っているのか UI やインフラに不変条件を置くと何が起きるか まとめ おすすめの関連書籍（無料） なぜクリーンアーキテクチャはドメインを守るのか クリーンアーキテクチャはドメインを守っているが、その本質は「判断」を守ることである はじめに 「クリーンアーキテクチャでは、ドメインを守ることが重要だ」 この説明を、これまで何度も目にしてきましたし、自分でも何となく理解しているつもりでした。 UI から独立させるため フレームワークに依存させないため テストしやすくするため どれも間違ってはいません。 ただ、実務で設計に向き合えば向き合うほど、 それで結局、何が一番大事なのか？ という疑問が残りました。 最近、その答えが少しはっきりしてきました。 クリーンアーキテクチャの本質は、 「判断をどこに閉じ込めるか？」を決める構造である という考え方です。 どの判断は UI に任せてよいのか どの判断はユースケースで行うべきか どの判断は、絶対に外に漏らしてはいけないのか この「判断の置き場所」を曖昧にしたまま設計すると、 責務が混ざり 修正のたびに迷いが生まれ 変更に弱い構造 になっていきます。 では、 絶対に外に出してはいけない判断とは何なのか？ その答えを整理するための言葉が、不変条件 でした。 （不変条件という言葉は、英語では invariant という言葉でよく使用されます） この記事では、 クリーンアーキテクチャを「判断の置き場所」という視点で捉え直し その中で不変条件がどんな役割を持つのか なぜ不変条件をドメインに閉じ込めるのか を、実務の感覚に近い形で説明します。 不変条件とは何か 不変条件とは、 どれだけ仕様や実装が変わっても、絶対に破ってはいけない前提 です。 UI が変わっても API が変わっても DB が変わっても これが壊れたら、そのシステムは成立しない そういう条件を指します。 例 ログインしていないユーザーは、保護された操作をできない 残高は常に 0 以上である 同じ支払いは二重に確定しない これらは ...