DDD和基础架构庞大的'域' - DDD在这里失败了吗？

Question

我公司很少开发像花哨的网络商店，财务系统，请求/结果API等......相反，对于许多应用程序，我们甚至不需要在我们这边存储数据，因此不需要存储库，实体。我们主要做的是为网络设备和设施创建管理系统。这意味着：

• 整个“域”是基础设施为主，随着数以百计的同步，状态协议
• 我们的大多数系统提供的内部插件写的功能，其中的配置，数据和方法紧密耦合
• 即使这是不好的做法，对于我们的东西，我们经常需要配置超出规定

现在我想知道 - 是DDD适用在这里吗？业务层是基础架构层时，将业务逻辑与基础架构层分开是否有意义？你有这种情况下的任何经验吗？怎样才能利用某些例如基础设施问题进入领域？

编辑

我道歉，如果我不清楚我的声明“当商业逻辑是基础设施层”。我非常清楚DDD中两层的目的和边界，但请参阅此示例：

客户端希望您编写SNMP设备管理软件。他并不关心SNMP本身，因为他甚至可能不理解协议，但他确实关心可以被视为“域”的“设备管理”部分。现在，SNMP是基于二进制数据的TCP/IP协议，并且有点复杂。如果你要自己写一个客户端实现，那么在接下来的几周内你可能就不会完成了。所以你会怎么做？你使用一个框架，一个包含所有幻想魔法的库，让你快速入门。

现在，SNMP是一个非常'动态'的协议。当你问设备的配置时，你不知道你真正得到了什么。但是您希望将此配置存储到数据库中（使用您的存储库），因为客户端要求您这样做。因此，您可以创建像十几个值对象，类等来表示设备可以具有的功能。但是SNMP库呢？那么，它为它自己的类提供了SNMP设备可以提供的每种可能的类型。而且由于该域永远不应该与基础设施层耦合，因此您只需花一天时间将映射器从域实体创建到SNMP类。

好，很好。一旦你完成了，客户端还有另一个要求：如果设备不再可用，他希望得到一个电子邮件。所以你创建你的email-sender-service，写一些业务逻辑，从配置文件中获取客户端的电子邮件。什么时候会发生什么？当然，当设备不可达时 - 您只能在基础设施层检测到。因此，你需要找到一种方法来通知域层关于基础设施层上的事件，例如，使用事件总线。再次，您需要从您的域层中的基础架构层引入一个概念：“DeviceNotReachableEvent”，它已经存在于SNMP库中。

您看到了哪里？对于基础架构层的每个问题，您必须在域图层中创建一个挂件，因为您的域是基于“外部”基础架构的东西。当然，网络上发生的事情是一个域名要求，但没有任何需要在没有DDD的情况下做近两次相同的事情。

Answer 1

当业务逻辑是基础架构层时，将业务逻辑与基础架构层分开有意义吗？

没有必要。但是，让我们来谈谈一些这方面更多...

您可能会产生混淆的基础设施问题是什么。 在DDD中，基础架构实质上是所有必须与技术依赖接口以驱动软件的代码。这将包括诸如数据库，应用程序接口，文件系统，网络关注等

但不是您的域名实际上是一个网络的关注？不必要。您的域可能具有所有与网络有关的聚合和服务，但这可能与可能为系统提供动力的实际网络基础设施问题完全不同。

您的竞争优势在哪里？

确定DDD是否适合您的一种方法是确定您的软件的所在地competitive advantage。

假设您正在开发网络设备的管理软件。您的域可以由表示网络节点的实体组成。这些对于使用您的软件的企业来说可能是非常重要的事情。他们想要在非常高的层次上管理节点（安全，分组，分配等）。决定并返回这些节点实体的基础“组件”可能必须实现一些非常繁重的网络代码才能遍历整个网络。可能有很多连接弹性和重试代码，协议握手，安全性等 - 这些都是涉及到查找这些节点的事情。业务用户并不关心所有这些东西 - 只要这些实体可用，它对于域如何实际完成并不重要。这是软件具有竞争优势的地方。

如果上面的例子不适合你，那么也许DDD远非理想。它是“节点管理”，将软件与其他软件分开吗？它是销售应用程序的“节点管理”吗？

或者它是你的优势的实际网络协议握手算法？ （我正在制作网络条款！）。在这种情况下，您的“域”取决于特定的技术问题。这不会是DDD的候选人。 PS：我对此一窍不通，所以请原谅我尝试使用网络术语！

Answer 2

DDD适用于域名复杂的各种应用。即有很多业务规则定义了对象如何工作以及它们如何相互关联。如果您的应用程序用于管理基础架构组件，则无关紧要。

您可以说CRUD应用程序在光谱的一端和另一端的DDD。也就是说，如果您的应用程序仅显示用户可以输入他们喜欢的任何形式的表单，那么DDD是非常不适合的。如果我们简化一点，如果你的应用程序是task based那么你可以使用DDD。