現場のプロダクトで、内部品質を高めるために定期的なリファクタリング習慣を取り入れて行きたく、リファクタリング計画を作るにあたり、目標とするアーキテクチャをはっきりさせたかった。構成は以下のようなレイヤーのマルチモジュール構成になっています。マルチモジュールにしている理由は依存性をシステム的に制御して人為的なミスによる間違った依存関係を生むのを減らすためです。mockk以下に、どのようにして上図のようになったかを解説します。(ライブラリはKotlinの言語仕様に合わせて簡単に書けるものやパフォーマンスが良いものを選んでいるつもりです。CleanArchitectureの基本的な考え方の1つである「関心事の分離」により、コンポーネント間、レイヤー間を切り離しを容易にすることで、柔軟性を上げます。関心事の分離の観点は以下の5つでフレームワーク非依存:システムをフレームワークに縛るのではなく、フレームワークをツールとして使う。テスト可能:ビジネスロジックはUI、DB、外部IFなどがなくてもテストできる。UI非依存:UIはシステムの他の部分を変更せずとも簡単に変更できる。(例えばビジネスロジック)データベース非依存:例えばOracleをMySQLに簡単に置き換えることができる。外部エージェント非依存:ビジネスロジックは外部IFの世界を知らなくて良い。これらを実現するためにソースコードの依存性は上位レベルの方針にだけ向かっていなければならないと言っています。最上位レイヤーは本質的な価値を持つ部分で、書籍ではビジネスモデルで相当すると言われています。この考え方をベースに、上位レベルのレイヤーは、アプリの価値を提供する部分として「ドメイン」と呼びたいと思います。(このネーミングが良いかは検討)また、このアーキテクチャはクライアント・サーバーモデルを前提にしています。何をドメインレイヤーにするか?アプリ内の処理の流れを大きくレイヤー分けすると、以下のように分けることができます。アクティビティやフラグメント、ビューなど。プレゼンテーションロジック:入力チェックや表示項目のフォーマットなど。ビジネスロジック:アプリにおけるビジネスロジック。アプリで利用するデータの加工やアプリ独自の機能のロジックなど。データアクセス:アプリ独自の項目を持つDBへのアクセスや、サーバーのエンティティに紐づくデータを持つDBへのアクセス、サーバーへのアクセスなど。データストア:SharedPreferencesやSQLiteなどのデータストア。この中からドメインを決定したいと思いますが、結論から言いますと全体的なバランスを考慮して、プレゼンテーションロジック、ビジネスロジックのレイヤーをドメインとしたいと思います。検討事項:データストア層のエンティティをドメインにしない理由アプリのビジネスルールは一見、データモデルとなるエンティティ(データストアの)になりそうです。クライアント(アプリ)・サーバー(API)を前提に考えると、サービス自体がサーバーありきで成り立つアーキテクチャであるため、実質、多くのエンティティはサーバーに依存していることになり、エンティティはアプリではコントロールしづらく安定度を高くできない可能性があります。これを踏まえると、愚直にデータストア付近のエンティティをドメインとするのはためらわれます。(そもそもサーバーをモデルとしているので、)検討事項:ビューをドメインにしない理由また、アプリの特徴としてUIのためのロジックを担うことが多いです。周りは一般的に変更頻度が高いためテストコード改修も高くなる可能性があり、ここもドメインにするにはためらわれます。残りのプレゼンテーションロジック、ビジネスロジックを見てみると、これらはビューとデータと切り離すことができるためテスト容易性が高くできます。機能自体もアプリの本質的な価値と言えるためこれらをドメインとして、安定度も高い状態にしていきたいと思います。