Clean Architecture on 設計で、迷わなくなるために | 奥田智紘

リポジトリがドメインに依存しすぎた話

Thu, 02 Apr 2026 13:00:00 +0900

題材
リポジトリがドメインに依存するのはありか？
ドメインを知りすぎた実装
ドメインを知りすぎない実装

今回は、リポジトリがドメインに依存しすぎた話を書きたいと思います。

題材

題材は、口座振替管理アプリで、ローカルの DB にデータを保存する場合の話です。

支払情報編集画面という画面があり、この画面では、データの新規登録と既存データの更新が可能になっています。

この「新規登録」処理と「更新」処理を行う際に、リポジトリはどこまでドメインを知っていていいのか？という話になります。

リポジトリがドメインに依存するのはありか？

まず、クリーンアーキテクチャ的には、リポジトリがドメインに依存することは間違ってはいません。

ただし、どこまで知っていてよいのかは検討の余地があるというのが今回の学びです。

ドメインを知りすぎた実装

まずは、ドメインを知りすぎた良くない実装を紹介します。

以下は、支払情報を表す Payment オブジェクトです。

sealed interface Payment {
 val name: PaymentName
 val payerId: PayerId

 data class Persisted(
 val id: PaymentId,
 override val name: PaymentName,
 override val payerId: PayerId = PayerId.NONE,
 ) : Payment

 data class InMemory(
 override val name: PaymentName,
 override val payerId: PayerId = PayerId.NONE,
 ) : Payment
}

編集の場合は、すでにデータが永続化されているため、 Persisted オブジェクトで表現します。永続化済みのデータは ID を持っています。

新規登録の場合は、 ID を持っていないため InMemory オブジェクトで表現します。

リポジトリ側には、この Payment オブジェクトが渡され、このオブジェクトの実態が Persisted なのか、 InMemory なのかによって、新規作成か、更新かを分けています。

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

Thu, 15 Jan 2026 00:00:00 +0900

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

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

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

はじめに

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

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

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

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

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

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

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

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

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

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

という考え方です。

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

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

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

になっていきます。

では、

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

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

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

この記事では、

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

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

不変条件とは何か

不変条件とは、

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

です。

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

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

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

例

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

これらは

クリーンアーキテクチャの本質をわかりやすく解説

Wed, 14 Jan 2026 00:00:00 +0900

アーキテクチャとは
依存関係とは
- 物理的な依存関係
- 意味的な依存関係
具体例
- 依存関係の逆転が必要なケース
- 依存関係を逆転させる具体的な方法
おすすめの記事
おすすめの本（無料）

クリーンアーキテクチャという言葉はよく聞くけれど、「わかったようでわからない」という人が多いのではないでしょうか？

クリーンアーキテクチャを解説した記事は、探せばすぐに出てきますが、あまり本質について語られている記事は少ないように感じます。

そこで、この記事でそれを簡潔に語っていこうと思います。

アーキテクチャとは

まず、そもそも「アーキテクチャ」とは何でしょうか？簡潔に説明したいので、どんどん答えを書いていきます。

目的
- 壊れにくいソフトウェアを作る
- チーム内で統一した方針でソフトウェアを作る
実現方法
- 部品 (※1) 同士の依存関係 (※2) を整える
- 部品が果たす役割・責務を明確にする

(※1) 「部品って具体的に何？」と思われた方は、一旦、クラスだと思っていただければ大丈夫です。 (※2) 後述します。

めちゃくちゃシンプルに書くとこうなると思います。

依存関係とは

クリーンアーキテクチャの本質を知るためには、このセクションがめちゃくちゃ大事です！！「そんなの知ってるわ」という方も、クリーンアーキテクチャについての理解が「モヤッ」としている方は読んでください。

依存関係には、二種類の依存関係があります。

物理的な依存関係

まずは、物理的な依存関係について説明します。これは、多くの人が最初に思い浮かぶ依存関係の方だと思われます。

すなわち、「どの部品 (クラスなど) がどの部品のことを知っているか」という関係性のことです。

(このドキュメントのサンプルコードは Kotlin で記述させていただきます。ご了承ください。)

class A {
 val b: B
}

class B {
 // ...
}

上記のサンプルでは、クラス A がクラス B を知っているので、これを「 A が B に依存している」と言います。

これが、物理的な依存関係です。 (超ざっくり)

意味的な依存関係

次に、意味的な依存関係について説明します。ここで、クリーンアーキテクチャの記事でよく出てくる同心円状の図を見て下さい。 (探せばすぐに出てくるのでここには載せません。笑)