复杂架构设计如何落地执行
主旨
企业架构
架构思维
组件建模
运营建模
功能性架构设计
-
关键认知：在个人视角里，整个世界都可以按照确定性内容和不确定性内容做简单区
分； -
架构将其抽象为元素和关系，元素对应着确定性内容的处理，是看待这个世界的稳定视
角；关系对应着不确定性内容的处理，是看待这个世界的响应视角； -
人类的理解能力有限。包含内容过多的元素，会导致理解困难，需要将其拆分；
-
同理，将元素归类的时候，也不能贪多，不然会导致理解困难。优秀的架构师，会将合
理数量的元素进行归类，归类后的整体一般被称作 component 或 module，也可以
直译为“组件”。比如，我们永远以“元素数量为 10 ”作为一个衡量点，只要一个组
件包含的元素 / 职责超过 10 个，就要进行拆分； -
元素归类一般采用 “V” 字型分析法，即流程分解为功能，功能聚合为组件；
-
如果组件明确了，意味着职责就建设好了，架构的元素（element）建设问题就解决
了。组件对外暴露的能力，我们统一称之为服务； -
那么，架构的关系（relationship）建设问题该如何解决呢？稳定的关系，用来表达确定
性的交互，使用 SOA 架构，做好服务调用就可以；不稳定的关系，用来表达不确定性
的交互，使用 EDA 架构； -
在每一个新需求到来时，尤其是大版本的更迭，架构师需要介入产品经理和程序员的沟
通中，判断新需求是否大幅增加了某些组件的复杂度，并决定是否调整组件职责，或对
现有组件进行拆分。所以，从实际的业务发展来看，组件的数量是逐步增长的，如果一
开始就很多，基本属于过度设计；如果业务复杂度已经翻倍了，组件数量却没变，基本
属于缺乏设计。
