DDD设计理解

Question

我已经开始学习DDD，我有几个问题，以便我可以提高我对它的理解。

因此，典型的DDD体系结构如下所示

域层=>这一层应该与技术无关，并且应该包含以下内容

Domain.Entities (与持久性层实体不同，应该只包含验证规则吗？)还有其他领域的业务应该在这里进行吗？)

Domain.ValueObjects (不需要在域中唯一的对象，应该只包含验证规则)

Domain.Services (此层应该包含业务逻辑，虽然与聚合相关，但不适合聚合本身)。需要多个Domain.Entities和/或Domain.ValueObjects协作的操作的协调器)

Domain.Factories (这个层在某种程度上没有被完全理解，我的意思是它的责任是创建集合或者什么?)它是纯粹的工厂设计模式，还是与之不同？

Domain.Repositories (这个层也是模棱两可的，除了我知道这个层负责与外部服务通信，它应该处理什么类型的业务逻辑？)

防损坏层(此层应充当域层和应用层之间的网关，负责将响应和请求从一个层转换到另一个层)

应用层=>只应用于以客户端易于理解的格式公开数据。过滤是在这个层(Linq-To-SQL) /(Linq-To实体)中完成的。

客户端(最后一层) =>应该没有任何逻辑，只公开应用层服务提供的模型。

我所看到的其他层

跨多个有界上下文共享的Shared.Kernel (Domain.ValueObjects / Domain.Entites (非AggregateRoots) )

Infrastructure.Domain.Common(跨整个域共享，如AggregateRoot、BaseEntity、BaseValueObject等)

Infrastructure.DataAccess.Provider(例如EntityFramework / nHibernate/ MongoDriver，这一层应该与谁通信？)应用层？

Answer 1

从DDD开始的地方是“蓝皮书”：艾瑞克·埃文斯的领域驱动设计

典型的DDD体系结构如下所示

分层结构。Evans概述了四个概念层

• 用户界面
• 应用程序
• 域名
• 基础设施

在第四章(隔离域)中，Evans指出

软件中专门解决领域问题的部分通常只占整个软件系统的一小部分，尽管它的重要性与其大小不相称。为了应用我们最好的思维，我们需要能够看到我们模型的元素，并将它们看作一个系统.我们需要将领域对象从系统的其他功能中分离出来，这样我们就可以避免将领域概念与仅与软件技术相关的其他概念混淆在一起，或者完全忽略领域。

在“域层”中，Evans识别了两组不同的关注点。

域实体、值对象和域服务在软件中对业务进行建模(第5章)。换句话说，这些元素为您的领域专家识别的概念建模。

存储库和工厂是生命周期问题--不像专家所认识的那样严格地与业务相关，而是充当应用程序层和域层之间的边界。

在Evan的公式中，业务规则的验证通常存在于域实体(而不是域服务)中。在OO样式中，域实体将状态(域值)和行为(更改规则)结合在一起--对持久化层实体的任何更改(您是正确的，而不是相同的事情)是因为域实体执行的代码。

反腐败层更多地是关于与外部数据源(可能是遗留系统)的集成，然后是与应用层的集成。

在现代应用程序和它所依赖的遗留系统之间实现外观或适配器层。该层在现代应用程序和遗留系统之间转换请求。使用此模式可以确保应用程序的设计不受遗留系统依赖关系的限制。

您可能需要查看github上可用的DDD示例应用程序。这是一个很好的草图，说明不同的部分是如何结合在一起的。

注意:现在，分层架构已经被其他一些替代方案取代了，我们开始看到更多的工作是用功能核心(而不是OO风格)实现域模型。

Answer 2

DDD没有定义分层方法。它只是建议使用一个。我建议阅读清洁/六角形/洋葱分层。这一方法与DDD一致，得到了广泛的认可。

六边形

打扫

洋葱

不要让不同的名字愚弄你，方法是非常相似的，如果不是相同的话。

Answer 3

老实说，领域驱动设计的前提将根据可能支配应用程序的应用程序需求、业务任务和底层体系结构而有所不同。领域驱动设计的最简单解释。

• 数据层:抽象的数据层，将关注点与图形用户界面分离。
• 域层:您的业务规则和逻辑，公司需求的基本基础，使命。
• 服务层:不是必需的，而是充当图形用户界面和数据层之间的中介。模型数据到业务实体之间的清晰、简洁的转换。
• 应用层:您的用户界面，以有意义的方式向用户提供核心业务功能。

这个重要的概念，没有一层相互依赖。他们都是独立的，互相恭维。您已经涉猎了更具体的上下文概念，并不是每个应用程序都是相关的或可行的。

根据你的例子，你可以把你的领域抽象到这样一个点，那就是该层可能是贫血的，没有足够的相关或有用的信息。传统的分层应用程序，如果用微服务方法、循环方法(干净的体系结构)或分层方法编写，可以是域驱动的设计。因为每一种方法或风格都使用领域驱动设计的基本目的，捕捉业务目的和使命。

应用程序不是域驱动的设计，因为您有一个层。您的应用程序将遵循一系列原则，以使域驱动设计兼容。这些原则是为了确保您的应用程序适应业务变化。持有代表业务的核心逻辑，同时，随着业务目标的变化，整个公司的生命周期都会发生变化。它们常常落在松耦合的一侧。

上面提到的层中有一半是解决问题的复杂模式。所有的工具都有目的，就像图案一样，螺丝刀被用来解决问题x，工厂可以解决x，但是存储库可以解决y，并不是每种模式都适合每一种用途。它们不是解决问题的办法。

在这个问题上有许多资料。福勒，埃文斯，沃恩和其他无数人。