业务逻辑能离frameworks/technologies多少？
How much can business logic be separated from frameworks/technologies?
最近我一直在重新考虑重构我的旧项目的各种方法，确保首先有一个合适的设计并将架构应用到代码中。
应用程序的业务逻辑应该与数据持久性实现、表示框架、技术甚至（理想情况下）编程语言无关。
我的问题是，您如何处理似乎与特定技术紧密耦合的使用 case/requirement？
在我的示例中，我希望在我的浏览器上查看来自微控制器的当前传感器值。可以通过将值存储在数据库中、读取它们并将它们发送到表示层来实现这一点。不过还有一种方式，貌似更快，听起来也更合理。通过使用 websockets，服务器将值中继到浏览器，服务器本身通过流从微控制器接收这些值。
这两种方法需要几乎完全不同的设计。第一个需要一个与持久层通信的存储库模式，而第二个则不需要。用例的数据流也不同。因此，满足相同需求的两个不同实现，仅仅因为技术和框架的选择而需要不同的架构。
是否仍然可以以不与两种实现之一耦合的方式设计架构？
完全有可能以与实现无关的方式描述功能需求和业务逻辑。
大多数情况下，这是使用用例和用例场景完成的。
请注意，用例场景未在 UML 中指定，但它们是行业中的 de-facto 标准。
我们的想法是您的用例代表应用程序提供的大（或多）功能块。它侧重于用户（参与者）的附加值，而不是实施方式。
在此级别的用例分析中要避免的典型事情是指定如下内容：
- 用户单击 "Details" 按钮
- 系统从数据库中获取详细信息并显示在详细信息中window
而是使用如下短语：
- 用户要求获取详情
- 系统显示详细信息
这使得分析独立于设计选择，例如使用按钮、菜单或功能键等。
另一方面，架构通常更多地绑定到特定的实现（模式），尽管它仍然可以独立于所使用的实际技术。
Is it still possible to design the architecture in a way that is not
coupled to one of the two implementations?
在某种程度上，是的 - 通过反转从传感器获取数据的代码位与可以在屏幕上看到它的代码位之间的依赖关系，即通过使前者不知道后者。几个选项可能是：
将微控制器输入流插入由责任链/处理程序模式组成的管道。一个处理程序可以将指标保存到数据库，另一个可以通过 websockets 发送数据。
采用event-driven方法。发出与来自传感器的传入指标相对应的事件并订阅它们。订阅者可以做很多事情，例如将数据保存到数据库或通过 websockets 发送。
当然，架构中负责覆盖 "last mile" 到浏览器的部分总是不同的，因为场景 #1 是来自客户端的 pull-based 方法，而 #2 是由服务器推送（网络套接字）。不过，如果您想显示 pseudo-real 时间数据，在场景 1 中，您可能必须通过某种轮询来模拟 #2。
最近我一直在重新考虑重构我的旧项目的各种方法，确保首先有一个合适的设计并将架构应用到代码中。 应用程序的业务逻辑应该与数据持久性实现、表示框架、技术甚至（理想情况下）编程语言无关。 我的问题是，您如何处理似乎与特定技术紧密耦合的使用 case/requirement？
在我的示例中，我希望在我的浏览器上查看来自微控制器的当前传感器值。可以通过将值存储在数据库中、读取它们并将它们发送到表示层来实现这一点。不过还有一种方式，貌似更快，听起来也更合理。通过使用 websockets，服务器将值中继到浏览器，服务器本身通过流从微控制器接收这些值。
这两种方法需要几乎完全不同的设计。第一个需要一个与持久层通信的存储库模式，而第二个则不需要。用例的数据流也不同。因此，满足相同需求的两个不同实现，仅仅因为技术和框架的选择而需要不同的架构。
是否仍然可以以不与两种实现之一耦合的方式设计架构？
完全有可能以与实现无关的方式描述功能需求和业务逻辑。
大多数情况下，这是使用用例和用例场景完成的。
请注意，用例场景未在 UML 中指定，但它们是行业中的 de-facto 标准。
我们的想法是您的用例代表应用程序提供的大（或多）功能块。它侧重于用户（参与者）的附加值，而不是实施方式。
在此级别的用例分析中要避免的典型事情是指定如下内容：
- 用户单击 "Details" 按钮
- 系统从数据库中获取详细信息并显示在详细信息中window
而是使用如下短语：
- 用户要求获取详情
- 系统显示详细信息
这使得分析独立于设计选择，例如使用按钮、菜单或功能键等。
另一方面，架构通常更多地绑定到特定的实现（模式），尽管它仍然可以独立于所使用的实际技术。
Is it still possible to design the architecture in a way that is not coupled to one of the two implementations?
在某种程度上，是的 - 通过反转从传感器获取数据的代码位与可以在屏幕上看到它的代码位之间的依赖关系，即通过使前者不知道后者。几个选项可能是：
将微控制器输入流插入由责任链/处理程序模式组成的管道。一个处理程序可以将指标保存到数据库，另一个可以通过 websockets 发送数据。
采用event-driven方法。发出与来自传感器的传入指标相对应的事件并订阅它们。订阅者可以做很多事情，例如将数据保存到数据库或通过 websockets 发送。
当然，架构中负责覆盖 "last mile" 到浏览器的部分总是不同的，因为场景 #1 是来自客户端的 pull-based 方法，而 #2 是由服务器推送（网络套接字）。不过，如果您想显示 pseudo-real 时间数据，在场景 1 中，您可能必须通过某种轮询来模拟 #2。