领域驱动代码结构图和说明

正文

1.代码分层

代码分层以六边型架构风格为基础，以领域模型为基础和核心，数据库，外部接口和MQ等为基础架构设施，通过适配器接入系统。放弃以数据，技术为中心，整个系统的分层不能再以数据库,技术为中心进行构建。目录结构和分层不再只有技术上的映射，更应该体现构建的业务系统的核心业务逻辑。分层如下图所示：

用户接口层：
用户接口对接用户界面，根据用户需要的查询组装对应的参数，转化为相应的领域对象调用相关的领域服务处理用户需求。改层包括controller，DTO等对象。

应用程序层：
应用程序层用于放置应用服务相关代码。应用程序服务负责聚合多个聚合根，处理跨多个聚合根的业务逻辑。

领域层：
领域层是整个系统的核心。实体，值对象，资源库，领域服务，领域事件等核心概念相关的代码都放置在该层中，系统的整个业务逻辑都应该在该层中。资源库在该层中以接口的形式存在，它的具体实现将放置在基础架构层中，在该层中资源库将以数据库无关的形式存在。

基础架构层：
基础架构层包括资源库实现，工具包，配置等和基础架构，技术实现有很大耦合的代码。

2.代码结构

2.1.项目结构

以订单中心为例，每个中心为一个maven多项目结构：

order-context：
订单中心的界限上下文，整个中心的核心逻辑位于该项目中。

order-api：
订单中心对外提供能力的接口位于该项目中，实现了上下文映射的发布语言模式。

order-server：
订单中心可以以Jar包或是以服务的方式和其他中心进行集成。该项目的内容就是当订单中心以服务的方式与其他中心进行集成时需要的文件和代码。

order-starter：
该项目的内容就是订单中心以JAR的方式和其他进行集成时需要的文件和代码。

2.2.项目代码结构

项目代码结构的核心思想为：

1. 结合DDD，包结构上需要体现聚合，实体，仓库等核心DDD概念。
2. 代码和代码结构都要体现业务领域的概念。
3. 领域模型应尽量封装在界限上下文中。

order-context：

代码结构说明：

目录	说明	内容
domain	领域层：中心的业务核心内容都在该层。该层按聚合分为子目录，如列子所示，分了订单聚合和配送聚合，每个聚合为一个目录	子目录：聚合，entity ：实体对象相关代码；vo： 值对象相关代码；service：领域服务相关代码 ；event：领域事件相关代码；repository：存储相关代码
application	应用程序层：包括应用服务，事务，日志，性能等横切关注点相关的代码。如果使用CQRS模式将包括query和command对象	子目录：service ： 应用服务相关代码；command：CQRS模式中command对象相关代码(可选)；query：CQRS模式中query对象相关代码(可选)
infra	基础架构层：包括资源库实现，工具包，配置等和技术实现有关系的代码。	子目录：config：应用配置相关代码；job：定时相关代码；utils：工具包相关代码；repository：redis：redis 存储实现相关代码；mongodb：mongodb 存储实现相关代码
interface	用户接口层：中心对外提供能力相关的开放接口以及相关的传输对象	子目录：dto：传输对象相关代码。为避免领域对象泄漏与其他中心进行交互时都使用传输对象，再由controller或相关的应用服务 将传输对象转换为领域对象。；event：应用事件相关代码。领域事件只在中心内部流转，如果需要通知其他中心，领域事件应该转换为应用事件

order-api：

代码结构说明：

目录	说明	内容
api	api层：中心对外提供的能力，接口相关的代码	子目录：dto ：传输对象相关代码 ；event：应用事件相关代码
sc	order-api的spring cloud实现

order-server：

目录	说明	内容
order	启动服务代码
resources	独立服务相关配置文件
Dockerfile	Docker配置文件

order-starter：

目录	说明	内容
adapter	实现API导出的对外接口，将这些接口从远程调用变为本地调用，直接调interface或application层的相关方法。

2.3.包括子域的中心

随着中心的发展它会包含越来越多的能力，当发展到一定程度时我们需要将中心拆分为多个子域。当中心有多个子域时，每个子域为一个maven子项目在现有层次的基础上将再加一层，如下图所示：

每个子域的项目结构也会遵巡以上项目的结构。