我的公司很少开发诸如精美的网店、财务系统、请求/结果 API 之类的东西......相反，对于许多应用程序，我们甚至不需要在我们身边存储数据，因此不需要存储库，实体。我们主要做的是为网络设备、设施创建管理系统。这意味着:
- 整个“域”都是基于基础设施的，拥有数百个同步、有状态的协议(protocol)
- 我们系统提供的大部分功能都是在插件内编写的，其中配置、数据和方法紧密耦合
- 即使这是不好的做法，对于我们的东西来说，我们经常需要配置而不是约定
现在我想知道 - DDD 在这里适用吗？当业务层是基础设施层时，将业务逻辑与基础设施层分离是否有意义？您有遇到过这样的场景吗？如何利用某些因素，例如基础设施问题进入该领域？
编辑
如果我的表述不清楚“当业务逻辑是基础设施层”，我深表歉意。我很清楚 DDD 中两层的目的和边界，但请看这个例子:
客户希望你编写一个 SNMP 设备管理软件。他并不真正关心 SNMP 本身，因为他甚至可能不理解该协议(protocol)，但他确实关心“设备管理”部分，可以将其视为“域”。现在，SNMP 是一种二进制数据、基于 TCP/IP 的协议(protocol)，并且有些复杂。如果您打算自己编写客户端实现，那么您可能无法在接下来的几周内完成。所以你会怎么做？您使用一个框架，一个包含所有奇特魔法的库，可以帮助您快速入门。
现在，SNMP 是一个非常“动态”的协议(protocol)。当您向设备询问其配置时，您不知道真正得到什么。但是您希望将此配置存储到数据库中(使用您的存储库)，因为客户端要求您这样做。因此，您创建了十几个值对象、类等来表示设备可以拥有的内容。但是 SNMP 库呢？嗯，它为 SNMP 设备可以提供的每种可能类型提供了自己的类。由于域永远不应该耦合到基础设施层，因此您只能花时间创建从域实体到 SNMP 类的映射器。
嗯，好吧。完成后，客户会有另一个请求:他希望在无法再访问设备时收到一封电子邮件。因此，您创建电子邮件发送者服务，编写一些业务逻辑，从配置文件中获取客户端的电子邮件......什么时候会发生什么？当然，当设备无法访问时——您只能在基础设施层检测到。因此，您需要找到一种方法来通知域层有关基础设施层上的事件，例如使用事件总线。再次强调，您需要从域层的基础设施层引入一个概念:“DeviceNotReachableEvent”，SNMP 库中已经存在的东西。
你知道这是怎么回事吗？对于基础设施层的每个问题，您都必须在域层中创建一个挂件，因为您的域是基于“外部”基础设施的东西。当然，网络上发生的事情是域要求，但如果没有 DDD，就不需要做几乎两次相同的事情。
最佳答案
Does it make sense to separate the business logic from the infrastructure layer when the business logic is the infrastructure layer?
不一定。但让我们再讨论一下这个......
您可能会混淆什么是基础设施问题。 在 DDD 中，基础设施本质上是必须与技术依赖项交互才能驱动软件的所有代码。这包括数据库、API、文件系统、网络问题等。
但是您的域实际上不是一个网络问题吗？不必要。您的域可能拥有所有与网络相关的聚合和服务，但这可能与可能为系统提供动力的实际网络基础设施问题非常不同。
您的竞争优势在哪里？
确定 DDD 是否适合您的一种方法是确定您的软件的 competitive advantage 在哪里驻留。
假设您正在开发网络设备的管理软件。您的域可以由代表网络上节点的实体组成。对于使用您的软件的企业来说，这些可能非常重要。他们希望在非常高的级别上管理节点(安全、分组、分配等)。确定并返回这些节点实体的基础设施“组件”可能必须实现一些相当繁重的网络代码才能遍历网络。可能有很多连接弹性和重试代码、协议(protocol)握手、安全性等——这些都是查找这些节点所涉及的事情。业务用户并不关心所有这些东西 - 对于域来说，它实际上是如何完成的并不重要，只要这些实体可用即可。这就是该软件的竞争优势所在。
如果上面的例子不适合您，那么 DDD 可能远非理想。是“节点管理”将您的软件与其他软件区分开来吗？是“节点管理”推销了您的应用程序吗？
或者您的优势是实际的网络协议(protocol)握手算法吗？ (我在这里编造网络术语!)。在这种情况下，您的“域”取决于特定的技术问题。这不适合 DDD。
PS:我对此一无所知，所以请原谅我尝试使用网络术语!
关于c# - DDD 和基于重型基础设施的 'domains' - DDD 在这里失败了吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24428253/