浅谈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框架，本质上没有 什么严格的约束，对于业务代码，还是有非常好的指导建议，不一定非要严格的按照框架的要求来执行，但一定要有规范的思想，这才是核心的。

    实际开发中，做好分模块，分层次，做好命名规范+一定的充血模型，用好 扩展组件点的策略模式，相信代码就能做到简洁易懂！