架构设计与演进
架构设计与演进的思考。
架构到底是什么
架构也被称为软件架构
,是软件结构的抽象描述
。
架构是由架构元素
与元素之间的关系
组成,元素的划分、选型、交互
是架构的关键。
架构元素:组件/服务的划分与技术选型。
元素之间的关系:组件/服务之间的关联关系与交互方式。
架构的目标
架构的目标是解决利益相关者的关注点
(参考)。
利益相关者
是与当前架构有之间或间接关系的人,也就是当前架构的目标用户,例如,业务方、产品、开发、测试等等。关注点
是利益相关者
对于当前软件的认知及痛点。
解决不仅仅是解决当前的问题,还要有前瞻性(对未来业务变化的考量
)。
这也就是保证架构的可迭代、可演进。
架构是有生命的
。
好的架构生命周期很长,支持业务的快速迭代,不断演进、进化,
相反,不好的架构没办法支持业务的迭代,不得不得对架构进行重构、重写。
架构的基础
领域建模
好的架构离不开好的领域建模
。
领域建模
是架构设计的基础,它确保了架构设计的边界。
通过领域建模将领域知识转化为软件架构,这里离不开领域专家
的配合。
架构不是凭空想象的,是基于
对领域知识(领域专家提供)建模
的基础之上来设计的。
对于大部分人来说,当提及领域建模时往往觉得时高大上、遥不可及的事情,事实并非如此。
领域建模是业务高度抽象的产物,范围可大可小,但需要建模者充分理解并调研领域知识。
对领域知识理解不足,造成的建模不准确?
不要怕,最好的建模通过演进实现的,试错修正、试错优化。
真正的需求
架构设计的目标是通过构建合理的元素关系来满足用户的需求
。
由于视角的不同,利益相关者的关注点可能各不相同。
那么,好的架构一定是基于以下两点:
① 发现所有直接或间接的利益相关者;
② 沟通与理解利益相关者的关注点。
尽可能收集利益相关者的关注点
作为架构设计的基础。
如何把关注点转换为领域知识
是架构设计的必经之路。
最小化利益冲突
在沟通过程中,利益关注者之间往往会出现利益冲突的情况。
如何最小化或避免利益冲突也属于架构设计的一部分。
好的架构是基于充分的调研与思考,保持利益相关者之间的利益平衡
。
大中台小前台
的架构设计上是存在业务方与技术方的利益冲突
。前台业务方考虑的是
快速迭代试错
,而中台技术方考虑的是平台的稳定性与通用性
。
合理架构与过渡设计
什么是合理架构
?
① 满足大多数利益相关者的关注点
(功能点);
大多数意味着存在取舍,
合理的取舍
也是架构设计的一部分。
② 最少的开发成本、最快的上线速度
,满足业务方快速迭代试错;
快与质量差没有任何关系,
不要以快为不合格的架构设计而找理由
。
③ 可持续演进
的架构,需要经得起业务的不断演进。
刚好够用且可持续优化
即为合理,一切不以现状为基础的设计均属于过渡设计
。
开发人员,往往会把追求极致挂在嘴边,但是,
追求极致
实际上也是一种过渡设计。
追求极致必然会增加功能的复杂度,无论是人力成本还是时间成本都是无法容忍的。
架构设计需要从公司当前的业务、人员、成本等多方面考虑
,避免吹毛求疵、过渡设计。
"技术债"
这个词很流行,但不是所有的技术债都是无法避免的。架构的演进伴随着技术债的填补,也伴随着新的技术债的产生,但要
时刻警惕非必要技术债的产生
。
理想架构与架构演进
没有理想的架构,只有最合适的架构
。
无论哪个公司都会经历从简到繁的架构演变
的过程。
架构的演进
是建立在合理架构的基础之上。
SOLID设计原则主要用于解决如何构建可持续性的软件架构。
架构的演进不仅包含业务逻辑上的演进
,也包括领域模型的演进
。
业务逻辑上的演进
是指随着需求的不断迭代对原有业务逻辑的影响。
领域模型的演进
是指随着需求的不断迭代对原有领域模型有了更加清晰的定义,它是构建可持续演进架构
的基础。
架构设计的关键问题是划清边界
,而架构演进的关键问题是领域模型的不断演进
。
领域演进
随着业务的演进,领域模型会面临拆分的问题,同时也会产生各个细分领域的领域专家。
细分领域的领域专家
是细分领域建模的关键,也是细分领域架构设计的关键。
与此同时,架构也会面临一次拆分,不同的细分领域负责各自的架构设计,架构设计更加聚焦,这也是架构演进的必然结果。
架构闭环与优化
闭环
是指拥有一套完整的反馈机制,架构闭环
是指拥有一套完整的系统监控与预警机制。
架构演进包括两部分:性能演进
与逻辑演进
。
逻辑演进与性能演进是不和分割的。
逻辑的演进会推动性能的演进,性能演进是为了保证逻辑的演进。
架构闭环是性能演进的必要条件。
评估架构性能瓶颈、监测系统运行情况是性能演进
的关键。
架构与组织
康伟定律
:架构与组织是一一对应的关系。
好的架构是依赖优秀的人来实现的
,而优秀的人是依赖好的文化来吸引的
。
公司中总能听到一些提效的要素,例如,工具、技术、流程。
我们要使用最先进的工具;
我们要使用最牛逼的技术;
我们要推广最高效的流程。真的是这样吗?
架构设计时需要考虑架构维护成本,一般需要按照组织来拆解架构(组织 : 架构 = 1 : 1)。
按组织拆解架构的好处在于架构的高内聚
,也就是说以组织为单位划分架构设计与演进的职责
。
组织内部的架构设计更加聚焦,领域知识也更加聚焦,
从而,领域模型更加清晰,架构设计也会相对轻松(由于目标更聚焦了)。