【架构设计模式】设计经验

前言本文主要表达作为一名程序设计人员,甚至架构师在做设计的时候,经常要遵守的原则;但原则并不使用所有人,不同的设计思想对于不同的人有不同的认可程度,本文大部分

前言

  本文主要表达作为一名程序设计人员,甚至架构师在做设计的时候,经常要遵守的原则;但原则并不使用所有人,不同的设计思想对于不同的人有不同的认可程度,本文大部分偏向于协同而非编排的编程模式。

正文

1、减少副作用

  尽量不要在方法中去修改入参的值,对对象的内部修改,最后在一个方法中可见,如果迫不得已可以利用DDD中的三种避免副作用的实践:

  1. 断言副作用;
  2. 把代码分为命令和查询,查询用函数式编程;
  3. 释意命名选择器

2、查询与命令分离

  比较出名的有CQRS架构,分离后模型的演进会更加内聚;

3、分离复杂计算到Value Object中

  减少副作用,使得状态变更更加简单,而复杂计算可以随便嵌套使用。

4、事务的主线与支线分离

  程序的运行一般是一条线下来的,这条线最好是用作写业务主线的逻辑,而支线的逻辑应该使用一定的设计模式分离,例如:AOP,或者:配合观察者模式

5、领域隔离

  该观点来自DDD,领域隔离,要求领域干净,无其他领域逻辑,这些要求落实到实际,就是:

  • 不能依赖其他领域的实体,或者包
  • 领域之间的交互要用适配器,定义好接口,因为接口是无法避免的依赖,所以接口最好用https等实现,避免语言依赖
  • 数据库隔离,不能操作其他领域实体的数据库
  • 一个领域逻辑要闭环
  • 领域逻辑要和平台逻辑隔离,你可能知道DDD中服务是分领域服务和基础设施服务的,其实就是体现这种隔离的
  • 事务与事务隔离,一般领域隔离后,事务的隔离会定义在领域之间,一个领域一个事务,而且多支持事务失败重试,方便做幂等

6、构建与运行分离

  程序如果按照事件驱动,或者按照领域隔离,控制反转,那么一般你会发现,你会用到很多注册的动作;所以应该是有一段代码是用来执行程序之间的组装的,这段代码不涉及运行时,而是体现架构,就好比钢铁侠在战斗的时候,要先组装铠甲,然后再战斗,把这些组合控制和其他代码分开,用一个包表示,就是构建与运行分离的思想;

7、服务与框架分辨

  很多时候,你会打算做一段抽象,那么你一定要先给你的抽象定义性质,它到底是服务,还是二方包,是平台,还是容器,是有状态的,还是无状态的;所以思考好之后,或许会给你很大的灵感,到底是要怎么设计你的抽象;把服务与框架分离,有利于服用和代码管理

8、平台与业务隔离

  平台,顾名思义具有普适性,而业务则是变化多端的;

  很多时候我们一个应用都是纯业务代码,当这样的代码过大过复杂的时候,通常需要治理,治理的方式有很多,例如微服务,但如果你的业务逻辑能后向上抽象,使得其可以分离出一个平台出来,那么最好这样来做,因为这意味着,你把业务的治理推向了自动化的路线,平台就是负责完成自动化的职责,通过平台会自动化你的业务的一整个生命周期;把好处总结如下:

  • 升职加薪,你的老板leader最喜欢就是这类技术沉淀了
  • 轻松进行业务与业务之间的隔离,你的平台会运行很多业务,把他们用包隔离开来,无疑是治理代码的最佳实践;
  • 管理业务生命周期,很多业务都会有生命周期,那些混饭吃的产品基本会憋个见光死的业务给你,特别你是中台的时候,当你的业务无流量之后,可随时删除垃圾业务,避免形成垃圾堆
  • 平台升级,造化业务,当然平台升级风险也是很大,但必须利大于弊,当你把底层引擎升级后,所有上层业务都会受益

  常见的自动化平台入流程引擎,流程引擎不仅能让你知道你的每一个业务即时运行情况,历史流量,报错节点反应性能瓶颈等,所以请尽量隔离一个平台出来吧;

9、业务数据和平台数据分离

  数据一般可以归类为两种,一个是属于业务数据,一个是属于平台数据,为什么平台会有数据呢?因为平台在执行业务的时候,平台的执行上下文是具有状态的,有状态必然有数据作为状态表达载体;分离的理由

  • 不同领域,难免会有key冲突
  • 方便维护,一般平台数据比较固定及格式化

10、业务代码与技术代码隔离

  DDD中的核心思想之一,业务代码不变,需要技术更新迭代的时候,可以很好的支持,另外一个特定的技术代码在多个地方用到可以抽离出来,甚至可以做成技术中台。

 

您可能有感兴趣的文章
八种架构设计模式及其优缺点概述(上)

高级系统架构师学习(四)软件架构设计

数据仓库的架构与设计

高并发系统设计(二):架构分层:我们为什么一定要这么做?

软件设计是怎样炼成的(5)——规划系统的骨架(架构设计)(上篇)