浅谈COLA 4.0 架构
敲了多年的业务代码,维护过一个持续迭代7、8年的业务应用,对业务应用中的各种if、else 是深恶痛绝,当看到大牛的关于 复杂代码应对之道,是深表赞同。参考以下两篇文章:复杂性应对之道 COLA 4.0:应用架构的最佳实践,
对于复杂的应用,专家提出了2个主要的解决办法:1.DDD领域建模,2. 分层架构
复杂性来源
对于复杂性,专家提出了主要来源:用面向对象语言,去写面向过程的业务代码。个人对此是认同的,业务代码天然就是过程式的。
但同时也有其他的客观因素。
对于传统行业、小应用,业务代码一般是大量低水平外包程序员写的,几乎从始至终没有考虑过复杂性,后续改造问题,完成功能交付第一。
互联网大厂,程序员一般科班出身,基础知识扎实,水平高。然互联网行业实行敏捷开发,快速试错迭代,程序员需要满足产品的各种乱码星空的想法,往往会陷入各种急迫的需求开发的泥潭,没时间去重构代码。时间一久,加上本身业务就比较复杂,还要背负各种高可用指标KPI,几乎就没什么勇气去做代码重构了。
解决复杂性方法
理论与框架,源于日常的开发的提炼于总结。 日常开发中,我们其实做了很多来应对复杂性。
底层代码: 重构,设计模式
资源组织: 分包,分模块,按规则命名(统一前缀、后缀)
服务SOA:微服务
总结就是2条: 1.分治,把大的拆小。 大应用拆分多个应用,微服务调用,MQ异步调用。 单应用分模块,分包。
2. 约定形成共识。 包、类、方法的命名,资源的存放目录等,由约定形成共识,减少沟通阅读的成本。
我们的目的,是要达到一目了然的清晰。
借用一下专家的图,就是:
COLA 框架到底是什么?
COLA是Clean Object-Oriented and Layered Architecture的缩写,代表“整洁面向对象分层架构",这是作者的定义。 经过快速的迭代,演进,目前是4.0版本。架构的代码比较简单,没有复杂的概念与算法,只要花上1个上午就可以全部搞明白。
cola 4 本质就是:规范+可复用组件+鼓励充血Domain模型!
规范包括:java 文件、包、子模块的命名规范。
可复用的组件:日志拦截处理,异常定义与处理, 状态机,业务扩展点设计
最吸引我的就是这个业务扩展点设计,这也是解决业务复杂度,将面向过程的业务处理逻辑 面向对象化的核心所在。但这个又非常的依赖 的命名规范 与 Domain实体。
这个扩展点 大概就是设计模式里面的 策略模式吧,一个扩展点,就是一个精确的执行策略。
COLA 带来的问题、使用建议
COLA 框架带来一个非常典型的缺点(问题): domain 实体类爆炸!
命名规范中查询用Qry结尾,增删改用 CmdExe结尾,返回结果用Response ,每个业务方法来一套,还有各种Item、VO、BO、CO、DO,有些字段需要重复非常多遍,各种实体类的转换也是非常多的重复代码,多层次的转换链条,中间有1个断了,都没法输出正确。看看框架自带的Demo代码,大概5个实体表,sample代码里面的实体对象就快50个左右了。。
COLA框架,本质上没有 什么严格的约束,对于业务代码,还是有非常好的指导建议,不一定非要严格的按照框架的要求来执行,但一定要有规范的思想,这才是核心的。
实际开发中,做好分模块,分层次,做好命名规范+一定的充血模型,用好 扩展组件点的策略模式,相信代码就能做到简洁易懂!
posted on 2021-03-15 19:43 qingcaolin 阅读(8153) 评论(0) 编辑 收藏 举报