alibaba/COLA 4.0框架 DDD使用记录_cola4.0

背景

简介：开发团队之前没用过DDD开发。第一次用https://github.com/alibaba/COLA框架试着做项目，记录一些遇到的问题
https://github.com/alibaba/COLA

COLA框架

• COLA 4.0 简介
  https://blog.csdn.net/significantfrank/article/details/110934799

• 梳理项目结构与调用流程
  

开发情况

• 项目目标
  组织权限中心（新增企业/部门/员工，赋予角色，关联权限）
• 拆分模块
  企业，部门，员工，账号，角色，权限
• 开发人员任务分配
  一人负责一个模块的逻辑开发
• 开发流程

  Adapter层： 写对前端暴露接口
  app层： 校验处理参数，调用其他模块的服务
  Domain层： 写业务处理逻辑
  Domain-Gatway： 定义数据接口
  infra层： 实现数据接口

出现的问题

1. 面向表结构编程
   感觉这是最大的问题：项目设计时优先设计的表结构，拿传统的方法 用表结构倒推实体对象，把实体对象仅当成数据容器
   开发流程是 Mapper > Enitiy > Service > controller
   ddd要关注领域对象建模，可能先建领域对象再设计表会好点？

2. 没有规划模块之间的调用。
   调用其他模块的domain层接口时 功能与参数偏差严重

例：新建企业接口，需要同时创建默认部门，默认角色，管理员账号。 默认的对象不可编辑删除
但部门，角色，账号模块只提供了普通的创建接口，不满足创建默认角色部门账号的要求

3. 参数校验逻辑写在app层，domain层对其他模块提供接口时要重新校验参数
   这个问题属于 领域对象Entity没封装好。
   如果领域对象是普通的pojo，那对其他领域提供接口时还得在逻辑里加校验，防止调用入参不合法
   正确做法是：在领域对象 内包含自检逻辑，确保入参合法
4. 业务逻辑分散，跨领域调用逻辑分散
   按ddd概念来说，跨领域对象的逻辑应该在 domainService。
   但对接时发现其他人逻辑没全写在domain层里，在app层的executor 校验参数时也耦合了一部分业务逻辑。。。难受
5. 公共代码分散
   工具类，枚举类等分散在Adapter层、app层、domain层。出现下层(domain)调用上层(app)代码的情况， 最终决定统一迁移到domain层

总结、建议

1. 优先领域对象建模，然后设计数据库对象
2. 业务逻辑、公共类 写在domain层
3. Entity 领域对象 包含自检逻辑