DDD领域驱动设计

DDD背后的一个原则是通过使用相同的语言来创建相同的理解来弥合领域专家和开发人员之间的差距。另一个原则是通过应用面向对象的设计和设计模式来降低复杂性，以避免重新发明轮子。

但什么是域？域是一个“知识领域”，例如公司运营的业务。域也称为“问题空间”，因此我们必须设计解决方案的问题。把大问题分成小问题，我们会看到子域的概念。

我们需要将子问题空间与我们的解决方案设计对齐，我们需要形成一个解决方案空间。DDD术语中的解决方案空间也称为有界上下文，并且最好将一个问题空间/子域与一个解空间/有界上下文对齐。

Domain和SubDomain构成了问题空间。界限上下文是对应的解空间。

DDD领域驱动设计将工程分为四个层：

展现层(Presentation)：向用户提供一个接口UI，使用应用层来和用户UI进行交互。

应用层(Application)：应用层是表现层和领域层能够实现交互的中间者，协调业务对象去执行特定的应用任务

领域层(Domain)：包括业务对象和业务规则，这是应用程序的核心层。

基础设施层(Infrastructure)：提供通用技术来支持更高的层。

领域层

领域层是实现所有业务规则的地方。

实体（Entity）： 实体代表业务领域的数据和操作，在实践中，通常用来映射成数据库表。

数据存储（Repository）： 在数据源库上检索和存储实体。在领域层定义数据存储，但是不实现它们。它们在基础设施层被实现。

领域服务（Domain service）： 当处理的业务规则跨越两个(及以上)实体时，应该写在领域服务方法里面。

领域事件（Domain Event）： 领域事件被用来定义特定于领域的事件，并且触发使用它们。领域服务与实体(以及其他领域对象)一起实现了不属于单个实体的业务规则。

工作单元（Unit of Work）： 工作单元是一种设计模式被用来管理数据库连接和事务，以及跟踪实体更改，并将这些更改保存到数据存储中。它被定义在领域层中，但是在基础设施层实现它们。

应用层

应用层提供一些应用服务（Application Services）方法供展现层调用。一个应用服务方法接收一个DTO(数据传输对象)作为输入参数，使用这个输入参数执行特定的领域层操作，并根据需要可返回另一个DTO。在展现层到领域层之间，不应该接收或返回实体(Entity)对象，应该进行DTO映射。 一个应用服务方法通常被认为是一个工作单元（Unit of Work）。用户输入参数的验证工作也应该在应用层实现。

基础设施层

当在领域层中为定义了数据存储接口，应该在基础设施层中实现这些接口。可以使用ORM工具，例如Hibernate。数据库迁移也被用于这一层。

链接

ABP总体介绍 - 层架构体系
Domain-driven Design Example