代码结构-可维护性代码

父文章  如何写可维护的代码 - 万物ddd ddd primitive . 封装,对象来实现可维护代码._fei33423的专栏-CSDN博客


[理论]领域驱动设计 DDD 是啥,cqrs是啥_个人渣记录仅为自己搜索用的博客-CSDN博客_cqrs ddd


错误码的设计


技术人人都是监控专家_个人渣记录仅为自己搜索用的博客-CSDN博客_fei33423 人人都是

java强编译之所以变成企业代码,是因为强对象的编译能力,可以callHiererachy, DDD不期望继承,而是期望组合,且组合是同bean不同包. 这样通过callHiererachy 可以快速的将代码区别. 代码面前了无秘密.

   map和配置过多会导致不可维护,但是面向接口编程,能避免顶层类爆炸,充分利用模板代码. 变和不变的逻辑得找出来. 1变多的时候,总能预估未来

1. 封装.

     现在的理解 就领域实体里的字段越来越少. 之前的理解 就是越上层参数越少. 

2. 同属异域

    同字段不同领域对象

3. 组合大于继承/回调/spi , 平台大于中台

     只有很稳定了,且回调的节点概念不业务化

4. 所有的可枚举值都封装成一个类,内部封装各个set方法 .这个类一定要加上domain前缀. 不要N个业务复用.  例如典型的就是PayerCardNo和PayeeCardNo 不要复用.

   或者status 字段不能暴露 set方法.

5. Exception和errorCode区别? 

       自动阻断.

接口一致性原则

   返回VO一样的才可以用一个接口. 不然接口不能任意插拔,多个接口之间必须强关联. 流程模板引擎大都有这样的问题,几个Handler接口(before,execute,after),返回是void,返回值通过context来传递. 另外一个问题是也非常影响后续的代码维护和阅读. 从一个after接口返回上来,再去看before接口的实现,不知道该看哪些. 只能通过一个流程对应的流程配置文件去看对应的代码. 如果是统一的VO的话,就完全可插拔替换.  流程模板见支付的文章. 

   这种模板和代码阅读的冲突怎么解? 我觉得没必要流程模板,DDD后,自然就类隔离. 不会出现很大的service,也不会出现一个service很臃肿,职责不单一的问题. finally处理这种全用拦截器设计模式替代. 

接口层叠原则

        接口可以返回接口,但最终的那个接口必须要符合上面的"接口一致性原则".

handler避免太多

   违反了"接口一致性"原则,也违反设计原则里面有个"接口隔离"  设计原则6大原则解读

面向配置的中台/后台系统

        由于配置化,枚举值都配置在数据库里,然后取出直接赋值到下游接口参数中. 一个枚举值代表一个能力,这个能力哪些地方被用了,无法逐级封装. 因为枚举值本身就是最上游入口处传下来的.

     解决方法 1.通过数据统计,自动识别枚举值和端码.代码阐释系统 从数据分析角度理解一个新系统  2.代码里不能直接将db里的枚举值配置传递给代码,需要转换成java里的代码类.

        代码面前不再了无秘密, 无法了解代码搭配组合. 需要通过数据统计和分析来发现秘密,结合端业务码,端事件码. 平台码意义, 应该是下游申请,给上,传递下来. 而不是现在上申请,传递给下.

         虽然业务上不能了解了,但是你的能力是通用的, 每个节点都是可插拔的.面向能力编程. 结合"接口一致性"原则好好思考下    

条件粒度小原则:

    当判断使用的的字段粒度很大时,就不合适. 那就细化到字段本身去写代码. 对字段本身(null值,其他逻辑进行判断). 最上游根据业务去获取字段本身的值即可. 一层变两层中转,大大复用了系统能力. 

字段不聚合,聚合后类不继承原则:

    领域字段本身也有根据业务去聚合的情况. 例如查询下游接口,某个业务有这些字段. 某个业务没有这些字段. 往往不上把这些字段平铺,而不是进行聚合. 然后后面的逻辑基于这几个类去执行. 这也是一种违背原则的错误. 很难发现.  还不如拉平 .因为你很难想象业务上的能力组合. 除非很确定可以分开. 平台系统拉平是最好的考虑.

配置聚合原则:

 例如账户类型的校验. 有很多字段,字段1是 普通账户是否校验 字段2是理财账户是否校验. 字段3是普通账户的风控校验 字段4是理财账户特有的校验. 所以就可以聚合成是什么账户类型. 每个账户各自的实体就出来了,(和字段不聚合原则不违背). 本质上还是要从上到下思考出领域实体. 根据领域实体去设置配置. 而不是从下而上的搞了很多processor去组合逻辑. 每个功能点就是一个processor但是思考角度有点太散,太小,没有一个从上到下的全局思维.

api层

    -domain

    -view (亮点 组合层,不属于纯碎的领域,比如修给订单费用接口,需要直接调用支付模块,然后透传给订单模块).  透传的属性用jsonString替代,泛化

biz层: 1.模块之间允许互相依赖.( 相当于互相的rpc调用 ) 2. 写不能夸模块,需要模块封装

integration: rpc调用的封装层. 1.人力沟通隔离 2. 技术上变化屏蔽.

service层: 不能互相依赖.

    不要直接用枚举，而是用自建枚举接口，方便后续用类替换值，重构。

dao层.

     不要用继承，用组合。例如orm继承通用的dao，对于具体某个对象的create就很难梳理，散失了java的编译优势。

     有人的话用引擎模式，没人的话用组合模式。

      有可能两个模块之间的计算封装又会产生新的类(模块): 举例, 订单和支付模块之前需要对 订单的给的费用进行计算转换. 给出支付费用.

同时.

分润的费用也最好放到该模块内去. 隔离领域和变化. 实现高内聚,低耦合. 

模块划分总的文章. http://blog.csdn.net/fei33423/article/details/51278704

只做存储平台+接口 还是 做包含业务的接口.

举例:  操作日志,有个type字段.

只是存储平台. 不定义type的取值. type和key的唯一性有外部决定. 

做包含业务的模块. 不能让调用方传入type. 需要通过接口封装掉.

微服务化会遇到这种基础服务的问题: 导致唯一性不好统一控制. 一种是type ,另外一种是 redis key.

通过约定来控制. 字符串前缀.

另外一个问题是 组合服务view逻辑大量存在.