私はCLEANアーキテクチャのプロジェクトで作業していますが、プロジェクトは「プレゼンテーション」、「ドメイン」、「データ」モジュールに分割されています。ここで、ドメインモジュールは、基本的にこのプロジェクトに固有のデータモデルです。このアーキテクチャの例はhereです。パーセルでAndroidでCLEANアーキテクチャを使用
"Domain"は純粋なJavaライブラリモジュールです。Androidのオーバーヘッドを持たないため、わかりやすくテストするのに最適ですが、今ではライブラリを使用できません非常にAndroid固有の「パーセル」のようなものです。これを回避する方法はありますか？
Parcelerを使用すると、特定のモジュールの外にBeanをコンフィグレーションして、@ParcelClass注釈で折り返しParcelableを生成できます。これは、指定されたBeanをデータレイヤーの外側とプレゼンテーションレイヤーの外に（または任意の場所で）@Parcelとして設定できることを意味します。詳細については、http://parceler.org/#classes_without_java_sourceを参照してください。
org.parceler：parceler-apiモジュールも純粋なJavaであり、Android APIに依存しません。したがって、探しているクリーンアーキテクチャに違反することなく、データモジュールに注釈を付けることができます。ただし、ライブラリの注釈コンパイラ部分（org.parceler：parceler）はAndroid APIに依存しているため、Android固有のモジュールで実行する必要があります。これはフォローであなたを残します：
あなたのデータモジュールでparceler-APIライブラリをインクルードし、データ層豆（@Transient、@ParcelProperty、など）を注釈します。特定の設定が不要な場合は、parceler-apiを依存関係として含めないでください。
parcelerとparceler-apiライブラリをAndroid固有のモジュール（Presentation？）に追加します。
データモジュールの各クラスに@ParcelClass注釈を追加すると、@Parcelの任意のクラス（Application？）になります。これにより、Parcelerは@ParcelClassパラメータ内で識別される各クラスに対してParcelableを生成します。
テスト用にのみ異なるパッケージまたはフレーバーを作成できます。シリアル化可能なパッケージクレートクラスにあります。テストのためにはシリアライズ可能になり、プロダクションではParcelableを使用します。 – androidnoobdev