クリーンアーキテクチャ-ユースケースクラスが多すぎる

私はクリーンアーキテクチャに入り、AndroidレベルをMVCからMVPに上げ、Dagger 2でのDI、RxJava 2での反応性、そしてもちろんJava 8を紹介します。

でMVPクリーンなアーキテクチャが存在し、エンティティ間の層（データストア内）とプレゼンターそれらにアクセスする必要があります。このレイヤーが「ユースケース」です。使用例は、理想的には1つのエンティティに1つの操作を実装するインターフェースです。

また、Clear Architectureは「悲鳴を上げている」ことも知っています。そのプロジェクトの意味では、クラスの数が多いため、非常に読みやすくなっています。

今、私のプロジェクトでは、6つの異なるエンティティのようなものがあり、もちろん、各エンティティリポジトリには、それらにアクセスするための少なくとも4つのメソッド（通常はget、add、delete、update）があります。つまり、6 * 4 = 24です。

Clean Architectureのこれまでに理解できたとしたら、24のUseCaseがあります。

MVCの6つのコントローラーと比較すると、これは多くのクラスです。

本当に24のユースケースを作らなければならないのですか？

私はすでにそれを成功裏に使っている誰かによる説明を本当に感謝します。

ありがとう、ジャック

本当に24のユースケースを作らなければならないのですか？

あなたが書くすべてがCRUDである場合のみ。

以下の図を参照してください。

あなたの主張は、6つの異なるエンティティーと、各エンティティーに対して4つのメソッド（作成、読み取り、更新、削除）があるということです。しかし、それはダイアグラムの中央にある黄色の円（エンティティレイヤー）にのみ当てはまります。EnsitiesレイヤーへのCRUD呼び出しを通過するだけの24のメソッドをユースケースレイヤーに作成しても意味がありません。

ユースケースは「顧客レコードの追加」ではありません。ユースケースは、「顧客へのアイテムの販売」（顧客、製品、および在庫エンティティが含まれます）または「請求書の印刷」（同じエンティティが含まれ、請求書ヘッダーおよび請求書ラインアイテムに加えて）に沿ったものです。 ）。

ユースケースを作成するときは、CRUDメソッドではなく、ビジネストランザクションについて考える必要があります。

さらに読む
集約-単一のユニットとして扱うことができるドメインオブジェクトのクラスター

すべてのCRUD-Operationが1つのUseCaseで翻訳されるのであれば、あなたは正しいです。ただし、UseCaseは複数のCRUD操作で構成される場合もあります。

UseCaseは、異なるデータソースから情報を収集し、データシンクへの通信を準備する独立したモデルです。複数のCRUD操作が含まれる可能性があります。

そのため、顧客の請求書を作成し、顧客もシステム内に存在しないため顧客自体も作成するUseCaseを考えてみてください。1つのトランザクションで少なくとも2つのCreate-Operationが発生するUseCaseが1つあります。

ユースケースの定義が間違っています。ユースケースはビジネスルールを実装するクラスです。CRUD操作である必要はありません。複雑なマルチステップ操作にすることができます