Domain

Domain と UseCase の違いを整理してみる 一言で言うと何が違うのか Domain とは何か Domain は「意味」と「ルール」の集合体 Domain の例 Domain がやらないこと UseCase とは何か UseCase は「動詞の層」 UseCase の例 Domain と UseCase の関係 なぜ UseCase が分かりにくいのか UseCase を作るべきタイミング Entity → Domain 変換はどこでやるべきか Domain と UseCase を分ける最大のポイント よくあるアンチパターン おわりに Domain と UseCase の違いを整理してみる Clean Architecture や DDD を学んでいると、ほぼ確実に次の疑問にぶつかります。 Domain と UseCase の違いがよく分からない どこまでが Domain で、どこからが UseCase なのか曖昧 UseCase を作ろうとすると、何を書けばいいのか分からない 私自身、このあたりで何度も立ち止まりました。 この記事では、実装経験を通して整理できた Domain と UseCase の違い を、自分なりの言葉でまとめてみます。 一言で言うと何が違うのか まず、かなり大胆に要約します。 Domain →「この世界では、何が正しく、何が成り立つか」を表す UseCase →「その正しさを、どういう手順・文脈で使うか」を表す ...

Domain レイヤーかどうかを判断する基準 Domain レイヤーとは何か（簡単に） 判断基準：ユーザーがそれを意識するか？ 例1：保存処理は Domain か？ ケースA：保存先をユーザーが意識しない場合 ケースB：保存先をユーザーが意識的に選択する場合 「ユーザーが意識する」という基準の使いどころ UseCase との関係 注意点：すべてを Domain に入れない 迷ったときの最終チェック おわりに Domain レイヤーかどうかを判断する基準 ―「ユーザーが意識するか？」という視点― 設計をしていると、次のような悩みにぶつかることがあります。 この処理は Domain レイヤーに置くべきか？ UseCase なのか、それとも Data レイヤーの責務なのか？ そもそも Domain って何を置く場所なのか？ とくに Clean Architecture や DDD を学び始めた頃は、 「正解の置き場所」を探そうとして、かえって混乱しがちです。 この記事では、私が設計を考える際に ひとつの判断基準 として使っている考え方を紹介します。 Domain レイヤーとは何か（簡単に） Domain レイヤーは、ざっくり言うと アプリが扱う 概念 その概念に関する ルール 「それは正しいかどうか」の判断 を表す層です。 技術的な詳細（DB、API、ライブラリなど）からは距離を置き、 アプリの意味そのもの を表現する場所だと考えています。 判断基準：ユーザーがそれを意識するか？ 私が Domain レイヤーかどうかを判断する際に使っている基準は、次の問いです。 「ユーザーは、その機能や概念を意識してアプリを操作するか？」 この問いに YES なら、 その概念や処理は Domain レイヤー（または UseCase）に属する可能性が高いです。 NO なら、 それは Data レイヤーや Infrastructure に閉じ込めるべきものだと考えます。 ...