业务逻辑可以与框架/技术分离多少？答案

【问题标题】：How much can business logic be separated from frameworks/technologies?业务逻辑可以与框架/技术分离多少？
【发布时间】：2018-08-29 14:35:11
【问题描述】：

最近我一直在重新考虑重构我的旧项目的各种方法，确保首先有一个正确的设计并将架构应用到代码中。应用程序的业务逻辑应该与数据持久性实现、表示框架、技术甚至（理想情况下）编程语言无关。我的问题是，您如何处理看起来与特定技术紧密耦合的用例/需求？

在我的示例中，我想在浏览器上查看来自微控制器的当前传感器值。可以通过将值存储在数据库中、读取它们并将它们发送到表示层来实现这一点。然而，还有另一种方式似乎更快，而且听起来更合理。通过使用 websocket，服务器将值中继到浏览器，服务器本身通过流从微控制器接收这些值。

这两种方法需要几乎完全不同的设计。第一个需要与持久层通信的存储库模式，而第二个则不需要。用例的数据流也不同。因此，满足相同要求的两种不同实现，仅仅因为技术和框架的选择而需要不同的架构。

是否仍然可以以不耦合到两种实现之一的方式设计架构？

【问题讨论】：

您所描述的业务逻辑在哪里？你是否以任何方式改变价值观？你所描述的只是一个管道，它似乎最适合流式传输......
@JohnGkikas “服务器本身通过流从微控制器接收这些值” - 两种方法都是这种情况吗？这是通过微控制器 API 获取输入的标准方式吗？
@SKleanthous 域指定传感器类及其字段（类型名称 id）和读取类（传感器 ID 读取），因此在存储之前，来自微控制器的输入应该由服务器上的处理程序，它调用服务将传入的数据转换为相应的域对象，然后调用存储库，使用可用的 ORM 操作该对象以实现持久性。我如何过滤值或应用策略是关于用例的，所以我调用一个服务，将这个逻辑应用到一个对象上并返回结果
@guillaume31 数据的形式和以固定方式发送到服务器的方式。处理程序服务理想地对此输入流做出反应并路由到将数据映射到域对象的方法，然后存储到数据库中（或中继到表示层）

【解决方案1】：

是否仍然有可能以一种不可行的方式设计架构？耦合到两个实现之一？

在某种程度上，是的 - 通过反转从传感器获取数据的代码位和可以在屏幕上看到数据的代码位之间的依赖关系，即让前者不知道后者。几个选项可能是：

当然，负责覆盖浏览器“最后一英里”的架构部分总是会有所不同，因为场景 #1 是客户端部分的基于拉的方法，而 #2 是服务器的推送（网络套接字）。但是，如果您想显示伪实时数据，在场景 1 中，您可能必须通过某种轮询来模拟 #2。

【讨论】：

【解决方案2】：

完全可以用与实现无关的方式来描述功能需求和业务逻辑。

这通常是使用用例和用例场景来完成的。
请注意，用例场景并未在 UML 中指定，但它们是业界事实上的标准。

这个想法是，您的用例代表了应用程序提供的大（ish）功能块。它专注于为用户（参与者）带来的附加价值，而不是它的实现方式。

在此级别的用例分析中要避免的典型事情是指定以下内容：

而是使用以下短语：

这使得分析独立于设计选择，例如使用按钮、菜单或功能键等。

另一方面，架构通常更受特定实现（模式）的约束，尽管它仍然可以独立于所使用的实际技术。

【讨论】：