业务逻辑应该在应用程序中还是在后端？

Question

最近，我开始在开发Android应用程序时应用清洁体系结构。所以我把我的申请分成四个不同的部分。

数据层

包含存储库的实现。

器件层

包含与安卓相关的东西的实现，比如AlarmManager，而不是实体的存储。

域层

用例( interfaces )在这里实现，存储库的接口在这里定义。

表示

UI相关的东西，片段，视图模型，活动。

这个应用程序不是孤立的，它存在于一个具有后端和前端(web应用程序)的系统中，其中一些用户使用移动应用程序，有些用户使用web应用程序。

现在，根据干净的体系结构，业务逻辑应该驻留在域层。但在这种情况下，我觉得它不属于那里。让我们举个例子。

假设用户可以从不同类型的电影院购买MovieTickets。

在这个场景中，我们将有一个名为PurchaseMovieTicket的用例。

现在的问题是。采购的实际逻辑应该在哪里实施？有两种方法可以做到这一点。

1型

大多数关于android上清洁架构的例子只将存储库看作是做CRUD操作的东西，不管是在云端还是在本地存储(例如。(机器人房)。这意味着PurchaseMovieTicket用例将包括逻辑，例如。

• 从用户处取出资金
• 将电影票添加到用户
• 以用户为参数调用存储库中的更新

这里的缺点是显而易见的。如果后端需要做其他与购买电影票有关的事情，甚至与其他系统通信，那么所有这些都需要在应用程序中实现。你几乎可以看到这是怎么不可能的。

2型

存储库包含一个名为purchaseMovieTicket的方法，它接受一个MovieTicket和一个用户。该方法将在后端或实现它的任何地方执行必要的逻辑。

这里的缺点是，用例几乎没有必要，因为它只是将调用从视图模型转发到存储库。也没有业务逻辑可以讨论。

问题

• 在这个系统中，哪种类型最好使用？为什么？
• 把业务逻辑放在后端好吗？
• 如果使用实现类型2，那么存储库是否破坏了干净的体系结构原则？

Answer 1

这应该是在逐个案例的基础上进行的，但我预计大部分逻辑都会出现在后台。

您的interactor可能仍然包含几种方法(“检查票证可用性”、“向篮中添加票证”、“签出”)，但在某些情况下，可以期望实现非常简单。

你不妨考虑：

• 安全系统。任何您需要信任的代码，都可以在后端实现。假设黑客可以更改客户端代码以实现他们想做的事情。在您的第1类型示例中，如果他们将其更改为只调用“向用户添加电影票”而不是“从用户中移除金钱”怎么办？
• 通信耦合正如您所提到的，对于任何需要与其他系统通信的东西，最好使用后端，这样客户端只需要与后端通信。
• 反应能力。客户端上的东西(除了繁重的计算之外)对于用户来说通常比与后端通信更好。出于这个原因，在客户端计算总篮子价格可能会更好。
• 重复。如果您有两个客户端，那么在客户机中实现逻辑将要求复制它，因此更倾向于后端。
• 数据定位。更喜欢将逻辑与它所操作的数据放在一起。例如，如果需要对后端数据库中的大量数据进行计算，但只向用户发送一个小结果，则将该逻辑放在后端。或者相反的可能适用。
• API接口。更愿意将逻辑放置在后端的API中，使其具有凝聚力和一致性。
• 种族条件。在后端放置逻辑可以更容易地使用事务和类似技术，从而降低并发问题的风险。
• 所需资源。在移动平台上，我建议在后端进行大量的计算。如果这是一个只运行在体面机器上的桌面应用程序，最好选择客户端来减少服务器负载。

注意，这不是一个详尽的列表。

Answer 2

术语“前端”和“后端”的定义来自业务逻辑(后端)与用户界面(前端)的分离。因此，是的，业务逻辑应该位于后端，无论是远程服务还是同一应用程序中的一个不同的层。

考虑到您已经有了一个独立的后端系统，您应该主要将清洁体系结构应用于这个系统，这个系统应该包含所有的业务逻辑。移动应用程序可以被认为是后端系统UI层的扩展，因此没有自己的业务逻辑。所有的用例和存储库都在后端，而移动应用程序只是使用一个网关与后端对话。

Answer 3

我是一个DBA，而不是一个开发人员，所以我将为您提供一个亲db透视图。

使用数据库中存储的procs和表驱动值的组合来实现逻辑，web应用程序和移动应用程序都可以共享这些值，这意味着您可以获得安全性、性能和一致性。

它的另一个优点是，当您想要进行更改时，无论界面如何，该更改都会立即向所有用户推出。

这也意味着业务可以在不需要重新部署软件的情况下对行为进行更改。