COLA分层之后的应用职责划分

COLA和其他架构设计

架构设计经常提到的原则是解耦，常用的实现方式是依赖抽象，如果相关分层直接都是互相发现松耦合，那除了必要的关联方式将相关分层关系串联起来，都满足则分层的组合可用，否则可以视为无效配置（缺失配置，相关分层不生效，也不主动引入依赖）。

同注解，类似只要存在源码修改的，在设计上有什么原则

1. 如果只需要有配置组件支持，自动注入管理，无需多次修改源码（除增减依赖），是否可强制要求禁止源码侵入；
2. 如果存在业务需要特殊的实现，如何做到抽象依赖（无实现且配置不可用默认无效）；
3. 如果存在低侵入的代码修改，如何把控，以及后续维护，甚至是删除依赖；
4. 基础层的维护升级方式，如果没有与业务层良好分离，以及集中管理的措施，会造成基础层维护成本无线扩大；
5. 相关的回归验证原则，部分重点有效性。

可行性分析

通用的和个性化控制均在配置中管理，源码只处理最基础的业务逻辑。这相当于需要在配置的地方处理基础层与业务层的逻辑关系

例如
源码，包含默认的执行流程，如果存在配置的流程以配置的流程优先
class A
function a
function b

只要基本的业务处理不变，如果只是业务逻辑控制放在配置
trsFlowConfig
exeFlow：a-b
通过配置可以调整执行顺序，
exeFlow:b-a
那么后续的维护方式可能也会出现很大变化

针对每个具体的整体业务流程，建议分割维护

ABC.transactionFlow：
exeFlow:b-a

CDE.transactionFlow：
exeFlow:c-d
withTransactionControl:{c,d}

如果是类似这样的一半源码，一半配置，是否会增加一定的业务迭代成本