Android Clean Architecture：ドメインレイヤーの理解と実践ガイド

アンドロイドアプリが複雑になるにつれて、無秩序なコードベースは密接な結合や重複したロジック、脆弱なユニットテストを引き起こし、開発を遅らせる原因となります。クリーンアーキテクチャの原則はこれらの課題に対処するために設計されており、関心事の明確な分離を促進し、アプリケーションをよりスケーラブルで保守可能かつテスト可能にします。このアーキテクチャの中心には**ドメインレイヤー**があり、この層はビジネスロジックをカプセル化し、UIとデータ処理との間に明確な境界を設定する重要な役割を果たしています。本記事ではドメインレイヤーについて詳しく掘り下げ、その目的やベストプラクティス、Androidアプリケーションへの効果的な実装方法について説明します。

ドメインレイヤーとは、アプリケーションのコアビジネスロジックを扱うための層です。このレイヤーは、ユーザーインターフェースやユーザーとの相互作用を管理するプレゼンテーションレイヤー、データベースやREST APIなどからデータの保存と取得を行うデータレイヤーとは独立しています。プレゼンテーションレイヤーとデータレイヤーはドメインレイヤーに依存していますが、ドメインレイヤーはそれらから完全に切り離されています。この構造によって、UIフレームワークやデータソースの変更があってもビジネスロジックには影響を与えません。

ドメインレイヤーには主に以下の要素が含まれています：
- **ユースケース（インタラクター）**：特定のビジネスロジックを処理し、アプリ内でデータがどのように処理され使用されるべきかを定義します。

- **ドメインモデル**：ビジネスドメイン内のエンティティを表します。
- **リポジトリインターフェース**：データへのアクセス方法を定義し、データソース（例えば、データベースやREST API）に依存せずに内部構造からの切り離しを実現します。

## ドメインレイヤーの主な責任
✅ **ビジネスロジックのカプセル化とモジュール性の促進**
ドメインレイヤーは、ビジネスロジックを中心にまとめており、それによってプレゼンテーションレイヤーやデータレイヤーから独立させています。この層ではユースケースが定義されており、注文を行うことやユーザー入力を検証するなどの特定のビジネスワークフローを示しています。また、この層でロジックを分離することで、Kotlin Multiplatform（KMP）で共有できるため、iOSなど他のプラットフォームとのロジック重複が軽減されます。

✅ **ビジネスロジックとデータソースを切り離す** ドメインレイヤーは、具体的な実装ではなく抽象に依存することで、ビジネスロジックがデータソースから独立することを確保します。これにより、REST APIからGraphQLへの変更やデータベースプロバイダーの変更など、データの取得や保存方法を柔軟に変えることができても、コアのビジネスロジックには影響しません。 ✅ **テスト容易性の向上** ビジネスロジックを小さく単責任のクラスに分けることで、ドメインレイヤーはテストしやすさを高めます。ユースケースは抽象（例えばリポジトリインターフェイス）に依存しているため、依存関係をモックして孤立した状態でユニットテストを書くことが簡単になります。この設計はテスト駆動開発（TDD）をサポートし、高いテストカバレッジを保証します。 ✅ **プレゼンテーション層の複雑さ軽減** ビジネスロジックと変換処理を担当することで、ドメインレイヤーはViewModelがUI状態の管理だけに集中できるようにします。ビューからユースケースへ論理を移行することで、それらの再利用も可能になり、アプリケーション全体の保守性が向上します。その結果、プレゼンテーション層もより簡単にテストできます。 ❌ **データ保存や取得について責任を持たない** ドメインレイヤーはデータの永続化や取得には関与せず、その役割はデータレイヤーに属しています。このレイヤーにはリポジトリ、データソース、REST API、およびデータベースなどのコンポーネントがあります。したがってドメインレイヤー自体はどのようにデータが取得または保存されるかについて無関心です。

❌ **UIの状態管理には責任を持たない**ドメイン層はUIの状態を管理しません。これはプレゼンテーション層（ViewModel）が担当します。代わりに、ドメイン層はビジネスロジックを実行し、不変の結果を返します。---## **ユースケースの構造**ユースケースとは、単一のビジネス操作をカプセル化するクラスであり、再利用可能でテストが容易です。よく構築されたユースケースは、1つの公共関数のみを持ち、単一責任に焦点を当てるべきです。もしユースケースが複数の公共関数を持っている場合、それは多くの懸念事項を扱っている可能性があり、「単一責任原則（SRP）」に違反しています。そのような場合は、ロジックを別々のより集中したユースケースに分割することを検討してください。### ユースケース名付け規則ユースケース名は次の形式に従うべきです:> _**[動詞]**_ + _[_名詞_]_ + _UseCase_例:✅ _**`Get**CustomerBag_UseCase`✅ _**`Logout**User_UseCase`✅ C**acheO**_rderDetailsU_seCase### ビジネスロジックの定義ビジネスロジックは、アプリが異なる状況でどのように振る舞うかについて制御するルールや決定となります。それによって以下が決まります:- **データ処理方法 -** 表示前に変換処理を適用します。- **アクション実行タイミングと方法 -** 保存前にユーザー入力を検証します。- **アプリ内で異なる部分がどのように相互作用するか -** 責任範囲を明確に保ちます。### ユースケース依存関係ユースケースは抽象化と純粋なKotlin構造のみ依存すべきであり、プラットフォーム独立性が保たれるべきです。以下は何を含めるべきか避けるべきかについてのガイダンスです:✅ **他のユースケース -** 共有ビジネスロジック用（あまり使用しないことで過度なチェーン呼び出しを避けます）。✅ **純粋Kotlinユーティリティクラス -** 検証ルールや数字フォーマットなど再利用可能なロジック用です。✅ **リポジトリインターフェイス -** 具体的な実装に依存せずデータ層と対話します。❌ **Android依存関係 -** `Context`や`LiveData`、`Application`などは避けましょう。「LiveData」の代わりにはKotlin の `Flow` や `suspend` 関数 を使用してドメイン層との結合度が低い状態になります。### ユースケースによるデータ提供方法ユースケースはいくつか異なるメカニズムによってプレゼンテーション層へデータ提供します。それぞれ操作実行方法によります:- **通常関数呼び出し -** 同期操作向け（例：メモリ内チェック・簡易計算）。- **サスペンド関数 -** 非同期一次操作向け（例：ネットワークリクエスト・データベースクエリ）。- **フロー -** 時間経過による更新発信（例：データベース変更観察）。- **オブザーバブル/コールバック -** RxJavaベースアーキテクチャ向け。この選択肢では、その操作が即時軽量なのか非同期長時間運用なのかどうかによります。---## ユースケースで留意すべき最良慣行### 1. invoke演算子利用についてユースケースには単一責任がありますので、Kotlin の `invoke` 演算子 を使うことで関数として呼び出せます。同じメソッド呼び出しを書かななくて済むため直感的になります

GetCustomerBagUseCase @Inject constructor( private val userRepository: UserRepository, // interface private val bagRepository: BagRepository // interface) { suspend operator fun invoke(): Bag { val userId = userRepository.getUserId() return bagRepository.getCustomerBag(userId) }}

これによってViewModel内で呼び出す際も簡潔になり直感的になります

customerBag = getCustomerBagUseCase()

### 2. スレッド安全性保持についてユースケースは「メインスレッド安全」である必要があります。この文脈ではUIブロッキングなしでメインスレッドから呼ばれることが求められます。またREST APIコールやデータベースクエリ等長時間運用処理についてもデータ層へ委譲されます。そしてドメイン層ではI/Oバウンドスレッドへの切替えは禁止されており、その根元近くから背景スレッドへの切替えも行います。ただしCPU集中的作業—例えば並び替えや変換処理—の場合にはこの中でも `Dispatchers.Default` を使います。我々の商品群から取得した製品群へ加工・整形日付表示・割引計算等必要になる事態想像できますね。この場合次ようになります.- 【製品取得】→ データ層ハンドリング(例：REST APIまたはDBからリポート取得)。.- 【並び替え & 整形】→ ドメイン側ビジネスロジックこの商品の加工というCPU集約型作業もバックグラウンド環境下執行、一方UIフリーズ及びANR (応答不可アプリケーション) エラー防止にも役立ちます ✅ 最良慣行 : 重い計算処理だけでもバックグラウンド環境移転

FormatProductListUseCase @Inject constructor( private val productRepository: ProductRepository, // interface private val formatDateUseCase: FormatDateUseCase, private val calculateDiscountUseCase: CalculateDiscountUseCase, @CoroutineDefault private val defaultDispatcher: CoroutineDispatcher) { suspend operator fun invoke(): List<Product> = withContext(defaultDispatcher) { productRepository.getProducts() .sortedByDescending { it.price } .map { product -> val formattedDate = formatDateUseCase(product.createdAt) val discount = calculateDiscountUseCase(product.price)  product.copy( createdAt = formattedDate, discount = discount ) }}data class Product( val id: String, val name: String, val price: Double, val createdAt: String, val discount: Double = 0.0)} 

### この仕組み上手く機能する理由 ✅ データ取得仕事委譲先として機能させています 商品群獲得その内容自体今後考える方向性も明確ですが ドメイン側との一致点維持につながっています ✅ CPU集約型タスク向け利用者とも言える 「Dispatchers.Default」 使用細かな整列及び変換プロセス背景環境下進めればパフォーマンス高まりますので UIフリーズ防ぐ助力にも繋げられます ✅ テスト可能性増加目的為「CoroutineDispatcher」を注入しました テスト中ディスポッチャー置换容易さ及時制御条件下動作展開させそれ以外影響受験所落ち着いた予測できる結果得られ様々試験条件下独立出来ました ✅ ビジュアルロギング論題モジュラー化保持 クリーンコード設計目指しましょう 各日付整形割引値調整同様独自少ない及可視化改善としてチーム全体貢献できます 。### 3. 複数リポジトリからデータ統合複雑して見えてしまうため ViewModel また Repository 内部整理難しく感じられるものもあります。しかしながら より効果的なのはこちら方針採取して新設された ユーザービジョン 統合情報収集専門 リポート設定こそ望ましいという流れでしょう！ ✅ 最良慣行 : フロー経由商材統合&バッグ件数 簡潔提示```kotlinclass GetProductsWithBagCountUseCase @Inject constructor( private val productsRepository: ProductsRepository, // interface private val bagRepository: BagRepository, // interface private val userRepository: UserRepository // interface) { operator fun invoke(): Flow

 { var userId=userReposiotory.getUserId() return combine(productsRepositroy.getUserProducts(userId),bagRepositroy.getUserBagCount(userId)){products ,bagCount-> ProductsWithBagCount(products ,bagCount)}} data class ProductsWithBagCount(val products :List,val bagCount:Int)` `` ### なぜこれがお勧めなの？ ✅ `Flow.combine()` 利活用 自然派生情報気づけばどちらとも更新通知随時確認出来れば最新値伝播されてゆく仕組み頼んだあなた自身までできます！ ✅ ブロッキング主張無効 Data Fetching 非同期型フロー通じ進展迅速効果的遂げています！ ✅ ViewModelシンプル具現 化された唯一真実源収拾出来欠乏考慮要素各種倉庫取り扱い負担減少されていますお陰様ですね！

class ValidateUserRegistrationUseCase @Inject constructor(

    private val emailValidator: EmailValidator,

    private val passwordValidator: PasswordValidator

) {

    suspend operator fun invoke(

        email: String,

        password: String

    ): ValidationResult {

        return when {

            !emailValidator.isValid(email) -> ValidationResult.InvalidEmail

            !passwordValidator.isValid(password) -> ValidationResult.InvalidPassword

            else -> ValidationResult.Valid

        }

    }

}



sealed interface ValidationResult {

    data object Valid : ValidationResult

    data object InvalidEmail : ValidationResult

    data object InvalidPassword : ValidationResult

}

@ViewModelScoped class GetCustomerBagUseCase @Inject constructor() {}

@Module

@InstallIn(ViewModelComponent::class)

abstract class BagModule {

    @Binds

    @ViewModelScoped

    abstract fun bindGetCustomerBagUseCase(

        impl: GetCustomerBagUseCaseImpl

    ): GetCustomerBagUseCase

}

@HiltViewModel

class BagViewModel @Inject constructor(

    private val getCustomerBagUseCase: GetCustomerBagUseCase) : ViewModel() {

    

    private val _customerBag = MutableStateFlow<CustomerBag?>(null)

    val customerBag: StateFlow<CustomerBag?> = _customerBag.asStateFlow()

    

    fun getCustomerBag() {

        viewModelScope.launch {

            _customerBag.update { getCustomerBagUseCase() }

        }

    }

}

import dagger.Lazy



@HiltViewModel

class BagViewModel @Inject constructor(

    private val saveItemToWishListUseCase: Lazy<SaveItemToWishListUseCase>) : ViewModel() {



    fun saveItemToWishList(item: Item) {

        viewModelScope.launch {

            saveItemToWishListUseCase.get().invoke(item)

        }

    }

}