COLA和其他架构设计
架构设计经常提到的原则是解耦,常用的实现方式是依赖抽象,如果相关分层直接都是互相发现松耦合,那除了必要的关联方式将相关分层关系串联起来,都满足则分层的组合可用,否则可以视为无效配置(缺失配置,相关分层不生效,也不主动引入依赖)。
同注解,类似只要存在源码修改的,在设计上有什么原则
- 如果只需要有配置组件支持,自动注入管理,无需多次修改源码(除增减依赖),是否可强制要求禁止源码侵入;
- 如果存在业务需要特殊的实现,如何做到抽象依赖(无实现且配置不可用默认无效);
- 如果存在低侵入的代码修改,如何把控,以及后续维护,甚至是删除依赖;
- 基础层的维护升级方式,如果没有与业务层良好分离,以及集中管理的措施,会造成基础层维护成本无线扩大;
- 相关的回归验证原则,部分重点有效性。
可行性分析
通用的和个性化控制均在配置中管理,源码只处理最基础的业务逻辑。这相当于需要在配置的地方处理基础层与业务层的逻辑关系
例如
源码,包含默认的执行流程,如果存在配置的流程以配置的流程优先
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}
如果是类似这样的一半源码,一半配置,是否会增加一定的业务迭代成本