系统架构是在做什么

今天和同事交流一个问题时,我发现我们两个人描述同一件事情的方式很有意思, 拿出来和大家聊聊, 顺便说下架构在干什么.

我们系统中, 对接了几个渠道, 这些渠道基本都一样. 然后这几天我们又新接了一个新的渠道, 但是这个渠道和我们之前的流程中, 又些许不一样. 在需求分析时, 同事就心直口快的直接说:这个就是和xxxx渠道的流程差不多嘛,改下就好了.

确实, 这个是和原来的流程中有些许不同. 但是这个在架构中问题, 就不是这么考虑的.

我们架构, 考虑的是共性, 解决的也是共性问题. 而不是两者的差异性.

就好像刚才的讨论,作为一个架构, 是不会说这个和xxx流程差不多(差一点), 而是会说这个是XXXX流程的一个特例, 需要实现一个特例来解决.

前面的是开发, 后面的是架构

前面的代码会写成下面这样

原来的代码

1
2
3
4
流程1()
流程2()
流程3()
流程4()

修改后的代码

1
2
3
4
5
6
7
8
流程1()
流程2()
流程3()
if(特殊逻辑判断){
    流程4()
} else {
    流程4_1()
}

这类的代码在系统不停的重构中会奔溃

后面的架构, 代码会调整成

1
2
3
4
5
流程定义 流程 = 创建流程定义()
流程.流程1()
流程.流程2()
流程.流程3()
流程.流程4()

这个流程随便你调整, 这个系统架构都是不会奔溃了.

所以

架构,在解决相同,而不是不同. 我们, 在总结/归纳相似,而不是强调个体的差异性.

求同存异, 先求同.

共勉