ビジネスロジックはアプリ内にあるべきですか、それともバックエンド内にあるべきですか？
Android=アプリケーションの開発中にクリーンアーキテクチャの適用を開始しました。そのため、アプリケーションを4つの異なる部分に分割しました。
データ層
リポジトリの実装が含まれています。
デバイス層
Android AlarmManagerのような関連エンティティの実装が含まれていますが、エンティティのストレージには関連していません。
ドメイン層
ユースケース（インタラクター）はここで実装され、リポジトリーのインターフェースはここで定義されます。
プレゼンテーション
UI関連のもの、フラグメント、ビューモデル、アクティビティ。
このアプリケーションは分離されていません。バックエンドとフロントエンド（Webアプリ）が存在するシステムに存在し、一部のユーザーはモバイルアプリを使用し、一部のユーザーはWebアプリを使用します。
これで、クリーンなアーキテクチャによれば、ビジネスロジックはドメインレイヤーに存在するはずです。しかし、このシナリオでは、それはそこに属していないように感じます。例を見てみましょう。
ユーザーがさまざまなタイプの映画館からMovieTicketを購入できるとしましょう。
このシナリオでは、PurchaseMovieTicketという使用例があります。
今問題です。購入の実際のロジックはどこに実装する必要がありますか？これを行うには2つの方法があります。
タイプ1
Androidのクリーンアーキテクチャに関するほとんどの例では、リポジトリがクラウド上かローカルストレージ上かを問わずCRUD操作を実行するものとしてのみ考慮されます（例：Android Room）これは、PurchaseMovieTicketのユースケースになどのロジックが含まれることを意味します。
- ユーザーからお金を取り除く
- 映画チケットをユーザーに追加する
- パラメータとしてユーザーを使用してリポジトリの更新を呼び出します
ここでの欠点は明らかです。バックエンドが映画チケットの購入に関連する他のことを行う必要がある場合、おそらく他のシステムと通信する必要がある場合は、これもすべてアプリに実装する必要があります。これがどのようにして不可能であるかをほぼ理解できます。
タイプ2
リポジトリには、MovieTicketとユーザーを取得するpurchaseMovieTicketと呼ばれるメソッドが含まれています。このメソッドは、バックエンドまたは実装されている場所で必要なロジックを実行します。
ここでの欠点はよく、ビューモデルからリポジトリに呼び出しを転送するだけなので、ユースケースはほとんど不要になります。そして、話し合うビジネスロジックはありません。
質問
- このシステムで使用するのに最適なタイプはどれですか？どうして？
- ビジネスロジックをバックエンドに配置するのは良いことですか？
- 実装タイプ2を使用する場合、リポジトリはクリーンなアーキテクチャの原則に違反しますか？
それはケースバイケースであるはずですが、私はほとんどのロジックがバックエンドに入ると予想します。
インタラクターにはいくつかのメソッド（「チケットの可用性を確認する」、「バスケットにチケットを追加する」、「チェックアウト」）がまだ含まれている可能性がありますが、はい、場合によっては実装が非常に単純であることが期待できます。
次のことを検討してください。
セキュリティ。信頼する必要があるコードは、バックエンドに実装します。ハッカーがクライアントコードを変更して、やりたいことを実行できると仮定します。タイプ1の例で、「ユーザーに映画のチケットを追加する」だけを呼び出し、「ユーザーからお金を取り除く」を呼び出さないように変更した場合はどうなりますか？
通信カップリング。他のシステムと通信する必要がある場合は、クライアントがバックエンドとのみ通信する必要があるように、バックエンドを優先します。
応答性。クライアント側の処理（重い計算を除く）は、通常、バックエンドとの通信よりもユーザーのパフォーマンスが優れています。このため、合計バスケット価格を計算するようなものがクライアント側でより良いかもしれません。
複製。クライアントが2つある場合、クライアントにロジックを実装するには、それを複製する必要があるため、バックエンドを優先します。
データの場所。ロジックは、操作対象のデータとともに配置することをお勧めします。たとえば、バックエンドデータベースから大量のデータを計算する必要があるが、ユーザーに小さな結果しか送信しない場合は、そのロジックをバックエンドに配置します。または逆のことが当てはまるかもしれません。
[〜＃〜] api [〜＃〜]。バックエンドのAPIがまとまりがあり一貫性があると感じるようにロジックを配置することをお勧めします。
レース条件。ロジックをバックエンドに配置すると、トランザクションや同様の手法をより簡単に使用できるようになり、同時実行の問題のリスクが軽減されます。
リソース要件。モバイルでは、バックエンドで重い計算を行うことをお勧めします。これがまともなマシンでのみ動作することがわかっているデスクトップアプリである場合は、サーバーの負荷を減らすためにクライアント側を優先することをお勧めします。
これは完全なリストではないことに注意してください。
「フロントエンド」および「バックエンド」という用語のまさに定義は、ビジネスロジック（バックエンド）とユーザーインターフェイス（フロントエンド）の分離に由来しています。そのため、はい、ビジネスロジックは、それがリモートサービスであっても、同じアプリケーション内の別のレイヤーであっても、バックエンドにある必要があります。
すでに別のバックエンドシステムがある場合、すべてのビジネスロジックを収容するこのシステムに、Clean Architectureを主に適用する必要があります。モバイルアプリは、バックエンドシステムのUIレイヤーの拡張機能と考えることができるため、独自のビジネスロジックはありません。すべてのユースケースとリポジトリはバックエンドにあり、モバイルアプリはゲートウェイを使用してバックエンドと通信します。
開発者ではなくDBAですので、プロデータベースの視点を提供します。
Webアプリとモバイルアプリの両方で共有できるデータベース内のストアドプロシージャとテーブル駆動型の値の組み合わせを使用してロジックを実装すると、セキュリティ、パフォーマンス、一貫性が得られます。
変更を加えたい場合、その変更がインターフェースに関係なくすべてのユーザーに即座にロールアウトされるという追加の利点があります。
また、ソフトウェアを再展開することなく、ビジネスによって動作の変更を行うことができます。