COLA分层架构 COLA 4.0 架构分成COLA架构和COLA组件两个部分:COLA架构:关注应用架构的定义和构建,提升应用质量。COLA组件:提供应用开发所需要的可复用组件,提升研发效率。 COLA 4.0 框架 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模块、领域层、基础设施层 分层架构如下: COLA 4.0 分层架构 分包结构如下: COLA 4.0 包结构模型 1)适配层(Adapter Layer):负责对前端展示(web,wireless,wap)的路由和适配,对于传统B/S系统而言,adapter就相当于MVC中的controller; 适配层代码结构 2)应用层(Application Layer):主要负责获取输入,组装上下文,参数校验,调用领域层做业务处理,如果需要的话,发送消息通知等。层次是开放的,应用层也可以绕过领域层,直接访问基础实施层; 应用层代码结构 3)Client模块(Client Module):包含的代码应该是常见的服务接口Facade和DTO数据传输对象,如API、DTO、领域事件、Command和Query对象等等。 Client模块 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形式展现查询结果。服务可以独立部署,也可以拆分部署。数据库可以使用一个,也可以读写分离。 CQRS架构 在COLA 4.0中,已经移除了Command Bus和Query Bus的处理,进一步简化了COLA架构。业务调用时序图 我们通过分三个场景的UML时序图描述一下各模块之间的调用关系。主要差异在于应用层中的Command或Query执行器的处理过程。 场景一:Command或Query执行器直接调用Gateway接口,处理业务请求。 UML时序图:场景一 场景二:Command或Query执行器,调用领域服务(Domain Service),然后领域服务调用Gateway完成业务请求。 UML时序图:场景二 场景三:Command或Query执行器直接调用infrastructure层中定义的Mapper,完成业务逻辑处理。 UML时序图:场景三 下面说明整体调用过程和注意事项。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分层架构、包结构、以及业务调用关系图 代码参考:《COLA 4.x架构入门和项目实践》