Domain レイヤーかどうかを判断する基準
―「ユーザーが意識するか？」という視点―
設計をしていると、次のような悩みにぶつかることがあります。
- この処理は Domain レイヤーに置くべきか？
- UseCase なのか、それとも Data レイヤーの責務なのか？
- そもそも Domain って何を置く場所なのか？
とくに Clean Architecture や DDD を学び始めた頃は、 「正解の置き場所」を探そうとして、かえって混乱しがちです。
この記事では、私が設計を考える際に ひとつの判断基準 として使っている考え方を紹介します。
Domain レイヤーとは何か（簡単に）
Domain レイヤーは、ざっくり言うと
- アプリが扱う 概念
- その概念に関する ルール
- 「それは正しいかどうか」の判断
を表す層です。
技術的な詳細（DB、API、ライブラリなど）からは距離を置き、 アプリの意味そのもの を表現する場所だと考えています。
判断基準：ユーザーがそれを意識するか？
私が Domain レイヤーかどうかを判断する際に使っている基準は、次の問いです。
「ユーザーは、その機能や概念を意識してアプリを操作するか？」
この問いに YES なら、 その概念や処理は Domain レイヤー（または UseCase）に属する可能性が高いです。
NO なら、 それは Data レイヤーや Infrastructure に閉じ込めるべきものだと考えます。
例1：保存処理は Domain か？
ケースA：保存先をユーザーが意識しない場合
- ユーザーは「保存」ボタンを押すだけ
- データがどこに保存されるかは気にしない
- ローカルかクラウドかはアプリ側の都合
この場合、ユーザーが意識しているのは 「保存する」ことだけ です。
- Domain が知るのは「保存する」という意味
- 「どこに保存するか」は Data レイヤーの責務
Domain に
- SQLite
- Room
- Firebase
といった言葉が出てくる必要はありません。
ケースB：保存先をユーザーが意識的に選択する場合
ユーザーが 「ローカルに保存」 or 「クラウドに保存」 を明示的に選ぶ場合、「保存先」はユーザーにとって 操作上の意味を持つ概念 です。
ここで重要なのは、
- Domain が知るべきなのは 技術名 ではない
- Domain が知るべきなのは 選択肢が存在するという事実
という点です。
Domain では、
- 「ローカル」
- 「クラウド」
といった 概念 を扱い、 それをどう実装するかは Data レイヤーに任せます。
「ユーザーが意識する」という基準の使いどころ
この基準が役立つのは、次のような迷いどころです。
- フィルタ条件は Domain か？
- 並び順は Domain か？
- キャッシュ戦略は Domain か？
- List か Map かはどこで決めるのか？
その都度、
ユーザーはこれを意識して操作しているか？
と自分に問いかけると、 レイヤーの境界がかなりクリアになります。
UseCase との関係
UseCase は、
- ユーザーの操作
- ユーザーの意図
- Domain の概念を使った一連の流れ
を表す層です。
そのため、
- ユーザーが意識する操作
- ユーザーが選択する条件
- ユーザーの行動単位
は、UseCase に置かれることが多くなります。
Domain が「名詞」だとすると、 UseCase は「動詞」に近い存在です。
注意点：すべてを Domain に入れない
「ユーザーが意識するか」という基準は便利ですが、 すべてを Domain に押し込むためのものではありません。
- パフォーマンス最適化
- キャッシュの仕方
- 再試行ロジック
- 通信方法
これらは、たとえユーザーに見えていたとしても 意味ではなく実装の問題 であることがほとんどです。
ここは冷静に切り分ける必要があります。
迷ったときの最終チェック
最後に、私がよく使うチェックを紹介します。
この概念は、ユーザー向けの説明書に書くだろうか？
- 書く → Domain / UseCase 側
- 書かない → Data / Infrastructure 側
この問いを挟むだけで、 「なんとなく」でレイヤーを決めることが減りました。
おわりに
Domain レイヤーの判断は、 ルール暗記よりも 視点 の問題だと感じています。
「ユーザーが意識するか？」
この問いを持って設計すると、 ViewModel や Repository の責務も自然と整理されていきます。