CN112181375A - 一种基于ddd充血模型及cqrs的代码架构优化系统 - Google Patents

Abstract

本发明提供一种基于DDD充血模型及CQRS的代码架构优化系统，属于软件/数据处理技术领域，本发明包括架构分层、领域实体和查询模型；在主流三层架构背景下，通过架构分层的划分、领域实体的优化、查询模型的拆分，实现业务逻辑不依于实现细节等诸多特性。

Description

一种基于DDD充血模型及CQRS的代码架构优化系统

技术领域

本发明涉及软件/数据处理技术，尤其涉及一种基于DDD充血模型及CQRS的代码架构优化系统。

背景技术

在软件架构中，三层架构已经成为主流。三层架构是将整个业务应用划分为：界面层(表示层、表现层)、业务逻辑层、数据访问层。界面层显示数据和接收用户传输的数据，为软件提供交互式操作界面。业务逻辑层对具体问题进行业务逻辑判断与处理，实现三层之间的数据连接和指令传达。数据访问层提供了对数据库中数据的增加、删除、修改、查询等操作。三层中的数据传递通常由业务实体(entity)或数据传输对象(data transferobject)承担。

三层架构本质上是一种面向过程的编程思想，其特点如下：

1.业务实体类中只有属性没有方法。

2.业务逻辑层的类中只有方法没有属性。

3.通常将数据表结构映射为业务实体类。

三层架构的根本问题在于：内存模型通常与数据库模型保持一致。如果数据库模型粒度很小，大量的表连接导致难以开发、维护以及性能问题。如果数据库模型粒度很大，代码的质量(重用性、稳定性、扩展性)就会很差。由于没有从业务的角度去仔细定义每一个类，会导致随着业务的发展相关类持续增长且难以维护。更有甚者，将业务逻辑也写进SQL或JS语句里。

发明内容

为了解决以上技术问题，本发明提供了一种基于DDD充血模型及CQRS的代码架构优化方法。

本发明的技术方案是：

一种基于DDD充血模型及CQRS的代码架构优化系统，

包括架构分层、领域实体和查询模型；

所述架构分层包括领域层、用例层、适配层和框架层，其依赖关系为由外向内的；

所述领域实体采用包含属性和行为的实体对象设计；

所述查询模型分离了客户端的查询操作。

进一步的，

领域层封装了核心业务规则，一个领域实体既包含属性和行为，能以业务实体为核心灵活扩展；

用例层包含应用业务规则，整合并且实现了系统中需要的所有用例，这些用例协调着来往于实体之间的数据流；

适配层包含各种适配器，负责把从领域层和用例层流出来的数据转换成为更外面一层需要的数据格式；

框架层是最外面的一层，是很多工具或库的具体实现细节所在。

领域实体应该遵循面向对象设计，领域模型具备自己的属性行为状态，并与现实世界的业务对象相映射。

领域实体具备明确的职责划分，领域对象元素之间通过聚合和引用关系配合解决实际业务应用和规则。

进一步的，

采用独立的查询模型

将客户端请求分为命令和查询，命令通过领域对象进行增加、修改、删除业务逻辑操作，查询通过查询模型将数据库中的数据转换成需要的形式予以返回。

查询模型根据UI的需求变化而变化，同时隔离领域对象不受此变化的影响。

进一步的，

架构将代码整体划分为五个目录，可通过Java9模块系统或Maven聚合模块实现，或通过最简单的package进行划分。

领域层目录命名为domain,其中包括service、event、repository三个子目录；

a)domain目录中放置领域实体，领域实体是业务逻辑载体，实体使用领域名称命名；

b)service目录中放置领域服务，当业务逻辑不适合于放在领域实体中时使用领域服务，领域服务使用xxxService命名(xxx代表领域名称，下同)；

c)event目录中放置领域事件，当领域实体的状态发生了变化之后需要发出领域事件，领域事件是使用xxxyyyEvent命名(yyy代表操作)；

d)repository目录中放置资源库接口，资源库被业务用例使用、由provider提供实现，资源库使用xxxRepository命名。

用例层目录命名为usecase,其中包括command、query、event、impl四个子目录；

a)usecase目录中放置业务用例接口，业务用例接口使用xxxUsecase命名；

b)impl目录中放置业务用例实现，业务用例实现使用xxxUsecaseImpl命名；

c)command、query目录中放置DTO，划分为命令、查询两类，用于业务用例的参数或返回值。command使用xxxCmd命名，query使用xxxQry命名；

d)event中放置事件的监听器,监听器使用过xxx Listener命名。

适配层分为两部分：应用入口适配器目录和数据提供适配器目录；

a)应用入口命名为entry，其中包括rest、job、listener三个目录。

b)rest目录中放置rest api，用于响应rest请求，使用xxxRest命名，

c)job目录中放置定时任务，使用xxxJob命名。

d)message中放置消息队列接收器，使用xxxMessage命名。

e)数据提供命名为provider，其中包括db、mq、cache、search、file、external等目录，分别用于数据库访问、发送消息、缓存、查询搜索引擎、文件存储、调用外部服务等。

框架层目录命名为boot,其中包括config目录和main()方法，除此以外还应提供统一的依赖管理和构建方法；

a)config目录中放置全局配置，用于将各层组件整合到一起，其职责为依赖注入和框架集成。

本发明的有益效果是

1)框架无关，即架构设计不依赖任何一个既有的开发框架，因此理论上可以使用任何框架。

2)业务规则可测性，即可以方便地测试业务逻辑所涉及的代码，不依赖UI、数据库或者Web服务等外部元素。

3)功能实现不依赖UI的实现细节，比如同样一套后台系统可以用在Web应用，也可以用在App原生应用。

4)业务逻辑不依赖数据库的实现细节，可以把数据保存在Oracle、SQL server、MongoDB、Mysql等任意一种数据库中，同时业务逻辑不需要做任何改变。

附图说明

图1是本发明的架构分层示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例，基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

一、架构分层及依赖原则

架构整体分为领域层、用例层、适配层和框架层，如图1所示，。

领域层封装了核心业务规则，一个领域实体既包含属性和行为，能以业务实体为核心灵活扩展。

用例层包含应用业务规则，整合并且实现了系统中需要的所有用例，这些用例协调着来往于实体之间的数据流。

适配层包含各种适配器，负责把从领域层和用例层流出来的数据转换成为更外面一层需要的数据格式(比如转换成为适合数据库保存的格式，或者适合Web页面展示的格式)。

框架层是最外面的一层，是很多工具(或库)的具体实现细节所在，比如Web框架、数据库框架及驱动等。

架构示意图中每个同心圆代表了软件开发中的不同层，越是靠近中心，同心圆层所代表的东西越抽象。内部的层定义的是规则，外部的层定义的是实现机制。只允许外层的代码依赖内层的代码，反之则禁止。换言之，内部同心圆层的代码不应当知道任何外部同心圆层的代码，比如内层的代码一律禁止引用外层声明的函数、类、变量或其他任何元素。当有数据传递时，只允许外层接受内层的数据格式，反之则不允许。

二、合理的划分领域实体

领域实体应该遵循面向对象设计，领域模型具备自己的属性行为状态，并与现实世界的业务对象相映射。领域实体具备明确的职责划分，领域对象元素之间通过聚合和引用等关系配合解决实际业务应用和规则。可复用，可维护，易扩展，可以采用合适的设计模型进行详细设计。简而言之，领域实体应当持有业务逻辑方法而非仅被当做数据结构来使用。

三、采用独立的查询模型

将客户端请求分为命令和查询，命令通过领域对象进行增加、修改、删除等业务逻辑操作，查询通过查询模型将数据库中的数据转换成需要的形式予以返回。查询模型可以根据UI的需求变化而变化，同时隔离领域对象不受此变化的影响。

四、架构方案

架构将代码整体划分为五个目录，可通过Java9模块系统或Maven聚合模块实现，也可以通过最简单的package进行划分。

1)领域层目录命名为domain,其中包括service、event、repository三个子目录。

a)domain目录中放置领域实体，领域实体是主要的业务逻辑载体，实体使用领域名称命名。

b)service目录中放置领域服务，当业务逻辑不适合于放在领域实体中时使用领域服务，领域服务使用xxxService命名(xxx代表领域名称，下同)。

c)event目录中放置领域事件，当领域实体的状态发生了变化之后需要发出领域事件，领域事件是使用xxxyyyEvent命名(yyy代表操作)。

d)repository目录中放置资源库接口，资源库被业务用例使用、由provider提供实现，资源库使用xxxRepository命名。

2)用例层目录命名为usecase,其中包括command、query、event、impl四个子目录。

a)usecase目录中放置业务用例接口，业务用例接口使用xxxUsecase命名。

b)impl目录中放置业务用例实现，业务用例实现使用xxxUsecaseImpl命名。

c)command、query目录中放置DTO，划分为命令、查询两类，用于业务用例的参数或返回值。command使用xxxCmd命名，query使用xxxQry命名。

d)event中放置事件的监听器,监听器使用过xxx Listener命名。

3)应用入口适配层命名为entry，其中包括rest、job、listener三个目录。

a)rest目录中放置rest api，用于响应rest请求，使用xxxRest命名，

b)job目录中放置定时任务，使用xxxJob命名。

c)message中放置消息队列接收器，使用xxxMessage命名。

4)数据提供适配层命名为provider，其中包括db、mq、cache、search、file、external等目录，分别用于数据库访问、发送消息、缓存、查询搜索引擎、文件存储、调用外部服务等。

5)框架层目录命名为boot,其中包括config目录和main()方法，除此以外还应提供统一的依赖管理和构建方法(如：基于maven的pom.xml)。

a)config目录中放置全局配置，用于将各层组件整合到一起，其主要职责为依赖注入和框架(web框架、数据库驱动等)集成。

以上所述仅为本发明的较佳实施例，仅用于说明本发明的技术方案，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所做的任何修改、等同替换、改进等，均包含在本发明的保护范围内。

Claims (10)

1.一种基于DDD充血模型及CQRS的代码架构优化系统，其特征在于，

包括架构分层、领域实体和查询模型；

所述架构分层包括领域层、用例层、适配层和框架层，其依赖关系为由外向内的；

所述领域实体采用包含属性和行为的实体对象设计；

所述查询模型分离了客户端的查询操作。

2.根据权利要求1所述的系统，其特征在于，

领域层封装了核心业务规则，一个领域实体既包含属性和行为，能以业务实体为核心灵活扩展；

用例层包含应用业务规则，整合并且实现了系统中需要的所有用例，这些用例协调着来往于实体之间的数据流；

适配层包含各种适配器，负责把从领域层和用例层流出来的数据转换成为更外面一层需要的数据格式；

框架层是最外面的一层，是工具或库的具体实现细节所在。

3.根据权利要求1所述的系统，其特征在于，

领域实体应该遵循面向对象设计，领域模型具备自己的属性行为状态，并与现实世界的业务对象相映射；

领域实体具备明确的职责划分，领域对象元素之间通过聚合和引用关系配合解决实际业务应用和规则。

4.根据权利要求1所述的系统，其特征在于，

采用独立的查询模型

将客户端请求分为命令和查询，命令通过领域对象进行增加、修改、删除业务逻辑操作，查询通过查询模型将数据库中的数据转换成需要的形式予以返回；

查询模型根据UI的需求变化而变化，同时隔离领域对象不受此变化的影响。

5.根据权利要求2所述的系统，其特征在于，

架构将代码整体划分为五个目录即领域层目录、用例层目录、应用入口适配层、数据提供适配层、框架层目录；通过Java9模块系统或Maven聚合模块实现，或通过最简单的package进行划分。

6.根据权利要求5所述的系统，其特征在于，

领域层目录命名为domain,其中包括service、event、repository三个子目录；

a)domain目录中放置领域实体，领域实体是业务逻辑载体，实体使用领域名称命名；

b)service目录中放置领域服务，当业务逻辑不适合于放在领域实体中时使用领域服务，领域服务使用xxxService命名(xxx代表领域名称，下同)；

c)event目录中放置领域事件，当领域实体的状态发生了变化之后需要发出领域事件，领域事件是使用xxxyyyEvent命名(yyy代表操作)；

d)repository目录中放置资源库接口，资源库被业务用例使用、由provider提供实现，资源库使用xxxRepository命名。

7.根据权利要求5所述的系统，其特征在于，

用例层目录命名为usecase,其中包括command、query、event、impl四个子目录；

a)usecase目录中放置业务用例接口，业务用例接口使用xxxUsecase命名；

b)impl目录中放置业务用例实现，业务用例实现使用xxxUsecaseImpl命名；

c)command、query目录中放置DTO，划分为命令、查询两类，用于业务用例的参数或返回值。command使用xxxCmd命名，query使用xxxQry命名；

d)event中放置事件的监听器,监听器使用xxx Listener命名。

8.根据权利要求5所述的系统，其特征在于，

应用入口适配层命名为entry，其中包括rest、job、listener三个目录；

a)rest目录中放置rest api，用于响应rest请求，使用xxxRest命名，

b)job目录中放置定时任务，使用xxxJob命名；

c)message中放置消息队列接收器，使用xxxMessage命名。

9.根据权利要求5所述的系统，其特征在于，

数据提供适配层命名为provider，其中包括db、mq、cache、search、file、external目录，分别用于数据库访问、发送消息、缓存、查询搜索引擎、文件存储、调用外部服务。

10.根据权利要求5所述的系统，其特征在于，

框架层目录命名为boot,其中包括config目录和main()方法，除此以外还应提供统一的依赖管理和构建方法；

a)config目录中放置全局配置，用于将各层组件整合到一起，其职责为依赖注入和框架集成。

Images