架构设计与演进的思考。

架构到底是什么

架构也被称为软件架构，是软件结构的抽象描述。

架构是由架构元素与元素之间的关系组成，元素的划分、选型、交互是架构的关键。

架构元素：组件/服务的划分与技术选型。
元素之间的关系：组件/服务之间的关联关系与交互方式。

架构的目标

架构的目标是解决利益相关者的关注点（参考）。

利益相关者是与当前架构有之间或间接关系的人，也就是当前架构的目标用户，例如，业务方、产品、开发、测试等等。
关注点是利益相关者对于当前软件的认知及痛点。

解决不仅仅是解决当前的问题，还要有前瞻性（对未来业务变化的考量）。

这也就是保证架构的可迭代、可演进。

架构是有生命的。

好的架构生命周期很长，支持业务的快速迭代，不断演进、进化，

相反，不好的架构没办法支持业务的迭代，不得不得对架构进行重构、重写。

架构的基础

领域建模

好的架构离不开好的领域建模。

领域建模是架构设计的基础，它确保了架构设计的边界。

通过领域建模将领域知识转化为软件架构，这里离不开领域专家的配合。

架构不是凭空想象的，是基于对领域知识（领域专家提供）建模的基础之上来设计的。

对于大部分人来说，当提及领域建模时往往觉得时高大上、遥不可及的事情，事实并非如此。

领域建模是业务高度抽象的产物，范围可大可小，但需要建模者充分理解并调研领域知识。

对领域知识理解不足，造成的建模不准确？

不要怕，最好的建模通过演进实现的，试错修正、试错优化。

真正的需求

架构设计的目标是通过构建合理的元素关系来满足用户的需求。

由于视角的不同，利益相关者的关注点可能各不相同。

那么，好的架构一定是基于以下两点：

① 发现所有直接或间接的利益相关者；
② 沟通与理解利益相关者的关注点。

尽可能收集利益相关者的关注点作为架构设计的基础。

如何把关注点转换为领域知识是架构设计的必经之路。

最小化利益冲突

在沟通过程中，利益关注者之间往往会出现利益冲突的情况。

如何最小化或避免利益冲突也属于架构设计的一部分。

好的架构是基于充分的调研与思考，保持利益相关者之间的利益平衡。

大中台小前台的架构设计上是存在业务方与技术方的利益冲突。

前台业务方考虑的是快速迭代试错，而中台技术方考虑的是平台的稳定性与通用性。

合理架构与过渡设计

什么是合理架构？

① 满足大多数利益相关者的关注点（功能点）；

大多数意味着存在取舍，合理的取舍也是架构设计的一部分。

② 最少的开发成本、最快的上线速度，满足业务方快速迭代试错；

快与质量差没有任何关系，不要以快为不合格的架构设计而找理由。

③ 可持续演进的架构，需要经得起业务的不断演进。

刚好够用且可持续优化即为合理，一切不以现状为基础的设计均属于过渡设计。

开发人员，往往会把追求极致挂在嘴边，但是，追求极致实际上也是一种过渡设计。
追求极致必然会增加功能的复杂度，无论是人力成本还是时间成本都是无法容忍的。

架构设计需要从公司当前的业务、人员、成本等多方面考虑，避免吹毛求疵、过渡设计。

"技术债"这个词很流行，但不是所有的技术债都是无法避免的。

架构的演进伴随着技术债的填补，也伴随着新的技术债的产生，但要时刻警惕非必要技术债的产生。

理想架构与架构演进

没有理想的架构，只有最合适的架构。

无论哪个公司都会经历从简到繁的架构演变的过程。

架构的演进是建立在合理架构的基础之上。

SOLID设计原则主要用于解决如何构建可持续性的软件架构。

架构的演进不仅包含业务逻辑上的演进，也包括领域模型的演进。

业务逻辑上的演进是指随着需求的不断迭代对原有业务逻辑的影响。

领域模型的演进是指随着需求的不断迭代对原有领域模型有了更加清晰的定义，它是构建可持续演进架构的基础。

架构设计的关键问题是划清边界，而架构演进的关键问题是领域模型的不断演进。

领域演进

随着业务的演进，领域模型会面临拆分的问题，同时也会产生各个细分领域的领域专家。

细分领域的领域专家是细分领域建模的关键，也是细分领域架构设计的关键。

与此同时，架构也会面临一次拆分，不同的细分领域负责各自的架构设计，架构设计更加聚焦，这也是架构演进的必然结果。

架构闭环与优化

闭环是指拥有一套完整的反馈机制，架构闭环是指拥有一套完整的系统监控与预警机制。

架构演进包括两部分：性能演进与逻辑演进。

逻辑演进与性能演进是不和分割的。

逻辑的演进会推动性能的演进，性能演进是为了保证逻辑的演进。

架构闭环是性能演进的必要条件。

评估架构性能瓶颈、监测系统运行情况是性能演进的关键。

架构与组织

康伟定律：架构与组织是一一对应的关系。

好的架构是依赖优秀的人来实现的，而优秀的人是依赖好的文化来吸引的。

---

公司中总能听到一些提效的要素，例如，工具、技术、流程。

我们要使用最先进的工具；
我们要使用最牛逼的技术；
我们要推广最高效的流程。

真的是这样吗？

---

架构设计时需要考虑架构维护成本，一般需要按照组织来拆解架构（组织 : 架构 = 1 : 1）。

按组织拆解架构的好处在于架构的高内聚，也就是说以组织为单位划分架构设计与演进的职责。

组织内部的架构设计更加聚焦，领域知识也更加聚焦，

从而，领域模型更加清晰，架构设计也会相对轻松（由于目标更聚焦了）。