COLA分层架构
COLA 4.0 架构分成COLA架构和COLA组件两个部分:
- COLA架构:关注应用架构的定义和构建,提升应用质量。
- 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 4.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,完成业务逻辑处理。
下面说明整体调用过程和注意事项。
Adapter接收Cmd/Qry对象或者参数列表(Request Param)。如果请求参数是参数列表,则构造Cmd/Qry对象,然后调用App Service接口。
App服务接收Cmd/Qry对象,然后调用Cmd/Qry Executor(执行器),如上图所示,分为以下三种场景:
2.1. Command Executor 可以通过领域实体方法,以及Gateway接口,实现简单业务编排,完成业务请求。
2.2. 或者通过调用领域服务(Domain Service)实现复杂业务逻辑处理,然后在领域服务通过Gateway访问数据的持久化。
2.3. 或者直接跳过Domain层,在Qry Executor中调用infrastructure中的Mapper接口,访问数据库持久化操作。App服务、Command Executor(命令执行器)以及Domain Serivce都是无状态服务,本身不存储任务信息。
App服务负责实现对外暴露的API服务,然后调用Command Executor.
Domain Service 负责封装一个领域中跨实体操作的业务逻辑。App Service 负责封装跨领域实体操作的业务逻辑。
Gateway接口用来隔离技术实现细节,GatewayImpl实现领域层定义的Gate接口,负责数据的CRUD操作,数据库测可以是MySQL、NoSql、Elasticsearch、Redis、甚至Hadoop/HBase等
分层架构、包结构、业务调用关系
下图将COLA分层架构、包结构、业务调用关系,整合在一张图中。
代码参考:《COLA 4.x架构入门和项目实践》