我的公司很少开发像花式网店，金融系统，请求/结果API这样的东西......相反，对于许多应用程序，我们甚至不需要在我们这边存储数据，因此不需要存储库，实体。我们主要做的是为网络设备和设施创建管理系统。这意味着：
现在我想知道 - DDD适用于此吗？当业务层是基础架构层时，将业务逻辑与基础架构层分开是否有意义？你对这种情况有经验吗？如何利用某些例如基础设施问题进入域名？
修改
如果我不清楚我的陈述＆＃34; ，当业务逻辑是基础架构层＆＃34;时，我道歉。我很清楚DDD中两个层的目的和边界，但请看这个例子：
客户希望您编写SNMP设备管理软件。他并不真正关心SNMP本身，因为他可能甚至不了解协议，但他确实关心设备管理＆＃34;部分，可以被视为＆＃39;域＆＃39;。现在，SNMP是一种二进制数据，基于TCP / IP的协议，有点复杂。如果您打算自己编写客户端实现，则可能在接下来的几周内无法完成。所以你会怎么做？你使用一个框架，一个包含所有奇特魔法的库，可以让你快速入门。
现在，SNMP是一个非常动态的＆＃39;协议。当您询问设备的配置时，您不知道自己真正得到了什么。但是您希望将此配置存储到数据库中（使用您的存储库），因为客户端要求您这样做。因此，您可以创建十几个值对象，类等来表示设备可以拥有的内容。但是SNMP库怎么样？好吧，它附带了自己的类，用于SNMP设备可以提供的每种可能的类型。由于域永远不应该耦合到基础架构层，因此您只需花费一天时间从域实体创建映射器到SNMP类。
好吧，好吧。完成后，客户端会有另一个请求：如果设备无法再访问，他希望获得电子邮件。因此，您创建了email-sender-service，编写了一些业务逻辑，从配置文件中获取客户端的电子邮件..什么时候发生？当然，当设备无法访问时 - 您只能在基础架构层上检测到这些内容。因此，您需要找到一种方法来通知域层有关基础架构层上的事件，例如，使用事件总线。同样，您需要从域层中的基础架构层引入一个概念：A＆＃34; DeviceNotReachableEvent＆＃34 ;,这是SNMP库中已有的东西。
你知道这是怎么回事吗？对于基础架构层的每个问题，您必须在域层中创建一个吊坠，因为您的域是基于“外部”的东西。基础设施。当然，网络上发生的是域名要求，但如果没有DDD，几乎不需要做两次相同的事情。
答案 0 :(得分：1)
当业务逻辑是基础架构层时，将业务逻辑与基础架构层分开是否有意义？
不一定。但是让我们再讨论一下......
您可能会对基础设施问题感到困惑。 在DDD中，基础设施本质上是必须与技术依赖关系以驱动软件的所有代码。这包括数据库，API，文件系统，网络问题等等。
但是，您的域名实际上不是网络问题吗？不必要。您的域可能包含所有与网络相关的聚合和服务，但这可能与可能为系统提供动力的实际网络基础架构问题有很大不同。
您的竞争优势在哪里？
确定DDD是否适合您的一种方法是确定您的软件competitive advantage所在的位置。
假设您正在为网络设备开发管理软件。您的域可以包含代表网络上节点的实体。对于使用您软件的企业来说，这些可能是非常重要的事情。他们希望以非常高的级别管理节点（安全性，分组，分配等）。确定并返回这些节点实体的基础结构“组件”可能必须实现一些非常繁重的网络代码才能遍历网络。可能存在大量连接弹性和重试代码，协议握手，安全性等 - 这些都是查找这些节点所涉及的所有内容。业务用户并不关心所有这些东西 - 只要这些实体可用，它对域实际完成起来并不重要。这是软件具有竞争优势的地方。
如果上面的例子不适合你，那么也许DDD远非理想。它是“节点管理”将您的软件与其他软件分开吗？它是销售您的应用程序的“节点管理”吗？
或者它是您的优势的实际网络协议握手算法？ （我在这里编写网络术语！）。在这种情况下，您的“域”取决于特定的技术问题。这不是DDD的候选人。
PS：我对此一无所知，请原谅我对网络术语的尝试！答案 1 :(得分：1)
DDD适用于域复杂的各种应用。即，有许多业务规则定义了对象必须如何工作以及它们如何相互关联。您的应用程序是否用于管理基础架构组件并不重要。
你可以说CRUD应用程序位于光谱的一端，而DDD位于另一端。也就是说，如果您的应用程序只显示用户可以输入他们喜欢的内容的表单，那么DDD是非常不合适的。如果我们简化一下，如果你的应用程序是task based，那么你可以使用DDD。