最近，我一直在重新思考重构我的旧项目的各种方法，确保首先进行适当的设计并将架构应用到代码中。 应用程序的业务逻辑应该与数据持久性实现，表示框架，技术甚至（理想情况下）编程语言无关。 我的问题是，你如何处理用例/需求似乎与特定技术紧密耦合？
在我的示例中，我希望在浏览器中查看来自微控制器的当前传感器值。可以通过将值存储在数据库中，读取它们并将它们发送到表示层来实现这一点。然而，还有另一种看似更快的方式，听起来更合理。通过使用websockets，服务器将值传递给浏览器，服务器本身通过流从微控制器接收这些值。
这两种方法需要几乎完全不同的设计。第一个需要与持久层通信的存储库模式，而第二个不需要。用例的数据流也不同。因此，满足相同要求的两种不同实现仅仅因为技术和框架的选择而需要不同的架构。
是否仍然可以以不与两种实现之一耦合的方式设计架构？
答案 0 :(得分：1)
是否仍然可以以不是这样的方式设计架构 耦合到两个实现中的一个？
在某种程度上，是的 - 通过反转从传感器获取数据的代码位与使得可以在屏幕上看到它的代码之间的依赖性，即通过使前者不知道后者。有两种选择可能是：
将微控制器输入流插入由责任链/处理程序模式组成的管道。一个处理程序可以将指标保存到数据库，另一个处理程序可以通过websockets发送数据。
采用事件驱动的方法。发出与传感器传入指标相对应的事件并订阅它们。订阅者可以执行各种操作，例如将数据保存到数据库或通过websockets发送。
当然，该架构的一部分负责覆盖＆＃34;最后一英里＆＃34;因为方案＃1是来自客户端部分的基于拉取的方法，而＃2是服务器的推送（网络套接字），因此浏览器将始终不同。有可能如果你想显示伪实时数据，在场景1中你必须用某种轮询来模拟＃2。
答案 1 :(得分：0)
完全可以以与实现无关的方式描述功能需求和业务逻辑。
大多数情况下，这是使用用例和用例场景完成的 请注意，UML中未指定用例场景，但它们是业界事实上的标准。
这个想法是你的用例代表了应用程序提供的大型（ish）功能块。它侧重于用户（参与者）的附加值，而不是它的实现方式。
在此级别的用例分析中要避免的典型事项是指定以下内容：
而是使用如下的短语：
这使得分析独立于设计选择，例如使用按钮，菜单或功能键等。
另一方面，体系结构通常更多地绑定到特定的实现（模式），尽管它仍然可以独立于所使用的实际技术。