COLA 4.0 - DDD项目实践

COLA分层架构

COLA 4.0 架构分成COLA架构和COLA组件两个部分:

  1. COLA架构:关注应用架构的定义和构建,提升应用质量。

  2. COLA组件:提供应用开发所需要的可复用组件,提升研发效率。

COLA架构:关注应用架构的定义和构建,提升应用质量。领域模型对设计能力要求很高,没把握用好,一个错误的抽象还不如不抽象,宁可不要用,也不要滥用,不要为了DDD而DDD。

COLA架构各个包结构的简要功能描述,如下表所示:

层次 包名 功能 必选
Adapter层 web 处理页面请求的Controller
Adapter层 wireless 处理无线端的适配
Adapter层 wap 处理wap端的适配
App层 executor 处理request,包括command和query
App层 consumer 处理外部message
App层 scheduler 处理定时任务
Domain层 model 领域模型
Domain层 ability 领域能力,包括DomainService
Domain层 gateway 领域网关,解耦利器
Infra层 gatewayimpl 网关实现
Infra层 mapper ibatis数据库映射
Infra层 config 配置信息
Client SDK api 服务对外透出的API
Client SDK dto 服务对外的DTO

COLA 组件:提供了一些框架级别的功能,提供应用开发所需要的可复用组件,提升研发效率。

组件名称 功能 版本 依赖
cola-component-dto 定义了DTO格式,包括分页 1.0.0
cola-component-exception 定义了异常格式,主要有BizException和SysException 1.0.0
cola-component-statemachine 状态机组件 1.0.0
cola-component-domain-starter Spring托管的领域实体组件 1.0.0
cola-component-catchlog-starter 异常处理和日志组件 1.0.0 exception,dto组件
cola-component-extension-starter 扩展点组件 1.0.0
cola-component-test-container 测试容器组件 1.0.0

COLA框架职责划分

COLA框架主要分为适配层、应用层、Client模块、领域层、基础设施层

分层架构如下:

分包结构如下:

1)适配层(Adapter Layer):负责对前端展示(web,wireless,wap)的路由和适配,对于传统B/S系统而言,adapter就相当于MVC中的controller;

2)应用层(Application Layer):主要负责获取输入,组装上下文,参数校验,调用领域层做业务处理,如果需要的话,发送消息通知等。层次是开放的,应用层也可以绕过领域层,直接访问基础实施层;

3)Client模块(Client Module):包含的代码应该是常见的服务接口Facade和DTO数据传输对象,如API、DTO、领域事件、Command和Query对象等等。

4)领域层(Domain Layer):主要是封装了核心业务逻辑,并通过领域服务(Domain Service)和领域对象(Domain Entity)的方法对App层提供业务实体和业务逻辑计算。领域是应用的核心,不依赖任何其他层次;

5)基础实施层(Infrastructure Layer):主要负责技术细节问题的处理,比如数据库的CRUD、搜索引擎、文件系统、分布式服务的RPC等。此外,领域防腐的重任也落在这里,外部依赖需要通过gateway的转义处理,才能被上面的App层和Domain层使用。

6)启动模块(Start Module):Spring Boot的启动类,应用入口。没有任何逻辑,只需要配置 application.properties 配置文件。

CQRS架构模式

CQRS架构模式,在DDD中是一种很常见的模式,它的用途在于将Command与Query功能进行分离,让一些复杂的查询摆脱领域模型的限制,以更为简单的DTO形式展现查询结果。服务可以独立部署,也可以拆分部署。数据库可以使用一个,也可以读写分离。

在COLA 4.0中,已经移除了Command Bus和Query Bus的处理,进一步简化了COLA架构。

业务调用时序图

我们通过分三个场景的UML时序图描述一下各模块之间的调用关系。主要差异在于应用层中的Command或Query执行器的处理过程。

场景一:Command或Query执行器直接调用Gateway接口,处理业务请求。

场景二:Command或Query执行器,调用领域服务(Domain Service),然后领域服务调用Gateway完成业务请求。

场景三:Command或Query执行器直接调用infrastructure层中定义的Mapper,完成业务逻辑处理。

下面说明整体调用过程和注意事项。

  1. Adapter接收Cmd/Qry对象或者参数列表(Request Param)。如果请求参数是参数列表,则构造Cmd/Qry对象,然后调用App Service接口。

  2. App服务接收Cmd/Qry对象,然后调用Cmd/Qry Executor(执行器),如上图所示,分为以下三种场景:
    2.1. Command Executor 可以通过领域实体方法,以及Gateway接口,实现简单业务编排,完成业务请求。
    2.2. 或者通过调用领域服务(Domain Service)实现复杂业务逻辑处理,然后在领域服务通过Gateway访问数据的持久化。
    2.3. 或者直接跳过Domain层,在Qry Executor中调用infrastructure中的Mapper接口,访问数据库持久化操作。

  3. App服务、Command Executor(命令执行器)以及Domain Serivce都是无状态服务,本身不存储任务信息。

  4. App服务负责实现对外暴露的API服务,然后调用Command Executor.

  5. Domain Service 负责封装一个领域中跨实体操作的业务逻辑。App Service 负责封装跨领域实体操作的业务逻辑。

  6. Gateway接口用来隔离技术实现细节,GatewayImpl实现领域层定义的Gate接口,负责数据的CRUD操作,数据库测可以是MySQL、NoSql、Elasticsearch、Redis、甚至Hadoop/HBase等

分层架构、包结构、业务调用关系

下图将COLA分层架构、包结构、业务调用关系,整合在一张图中。

COLA分层架构、包结构、以及业务调用关系图

如果本文对你有帮助,别忘记给我个3连 ,点赞,转发,评论,

学习更多JAVA知识与技巧,关注博主学习JAVA 课件,源码,安装包,还有最新大厂面试资料等等等

咱们下期见。

收藏 等于白嫖,点赞才是真情。


猜你喜欢

转载自blog.csdn.net/uuqaz/article/details/125870253