Architecture 业务逻辑可以从框架/技术中分离多少？

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

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

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

---

是否仍有可能以不与两种实现之一耦合的方式设计体系结构？

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

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

其思想是，您的用例代表应用程序提供的功能的大（ish）块。它关注于用户（参与者）的附加值，而不是它的实现方式

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

• 用户单击“详细信息”按钮
• 系统从数据库获取详细信息，并在“详细信息”窗口中显示

而是使用以下短语：

• 用户要求获取详细信息
• 系统显示了详细信息

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

另一方面，架构通常更多地绑定到特定的实现（模式），尽管它仍然可以独立于实际使用的技术

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

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

• 将微控制器输入流插入由责任链/处理程序模式组成的管道。一个处理程序可以将度量保存到数据库，另一个处理程序可以通过WebSocket发送数据

• 采用事件驱动的方法。从传感器发出与传入度量相对应的事件并订阅它们。订阅者可以做很多事情，例如将数据保存到数据库或通过WebSocket发送数据

---

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

您所描述的业务逻辑在哪里？您是否以任何方式更改这些值？您所描述的只是一个管道，它似乎最适合流媒体…@JohnGkikas“服务器本身通过流媒体从微控制器接收这些值”-这两种方法都是这样吗？这是通过微控制器API获取输入的标准方式吗？@skleanthur域指定传感器类及其字段（类型名称id）和读取类及其字段（传感器id读取），因此在存储微控制器输入之前，应该由服务器上的处理程序处理，调用服务将传入的数据转换为相应的域对象，然后调用存储库，使用可用的ORM将该对象操作为持久性。我如何筛选值或应用策略与用例有关，因此我调用一个服务，将此逻辑应用于对象并返回outcome@guillaume31数据的形式以及以固定方式发送到服务器的方式。理想情况下，处理程序服务是对该输入流作出反应，并路由到将数据映射到域对象的方法，然后存储到db（或中继到表示层）非常简洁的答案！既然我读了你们的选择，我就想知道为什么我想不出这么简单的选择。特别是处理器部分。