程序员的自我修养 - 架构要素与认知

原创于 2025-07-11 17:22:21 发布 · 389 阅读

CC 4.0 BY-SA版权

文章标签：

本文探讨了程序员在架构设计中的核心认知与实践，从系统架构的基本定义、原则和方法入手，深入解析了“形式”、“功能”和“概念”三者之间的关系。文章还结合《软件设计的要素》等书籍内容，强调了“概念”在架构设计中的重要性，并通过银行业架构网络（BIAN）和最小企业架构的实际案例，展示了如何构建敏捷、可复用的业务平台。最后，作者分享了关于程序员底层思维、技术领导力以及架构演进的思考，为读者提供了全面的架构认知框架。

前言

“问渠那得清如许，为有源头活水来”，架构活动最难的是缺少最佳实践，外部声音也很多，所以我们还是需要多看看别人的想法和实践，找到一些有启发的资料记录一下。本文就是对一些书籍的笔记，恰好有一个相同的关注点，那就是架构，我想这些应该可以成为架构的关键参考和基础认知。

系统架构：形式、功能与概念

▐ 2.1 总体

《系统架构》这本书里面提到的一些基本概念，构建了我们日常架构活动的“元认知”，有较好的方法论指导价值，值得一读。本节就是此书的读书笔记。

主要的概念如下：

▐ 2.2 定义

概念	解释
系统	系统是由一组实体和这些实体之间的关系所构成的集合，其功能要大于这些实体各自的功能之和。
产品	产品是能够交换或具备交换潜力的事物。
价值	价值是有着一定成本的利益。利益就是由系统所创造的财富、名望或功用。观察者会对价值进行主观判断。成本是一种指标，用来衡量为了取得利益所必须出的代价。
形式	形式是系统的物理体现或信息体现，它存在或有可能于某段时间内稳定而无条件地存在，且对功能的执行起到工具性的作用。形式包括实体的形式及实体间的形式关系。形式先于功能的执行而存在。形式是系统/产品的一项属性。
形式关系	形式关系或结构，是形式对象之间有可能在某段时间内稳定而无条件存在的关系，它们可能有助于功能交互的执行。
功能	功能是可以产生或促进性能的活动、操作或转换。在经过设计的系统中，功能就是使系统得以存在的动作，它最终会令系统的价值得到体现。功能是通过形式来执行的，形式对功能起着工具性的作用。功能要从实体之间的功能交互中涌现出来。功能是系统/产品的一项属性。功能 = 过程 + 操作数。
功能关系	功能关系，是指用来完成某件事情的实体之间具备的关系，此关系可能涉及实体之间对某物的操作、传输或交换。为了强调其动态性，我们有时也会把功能关系称为交互（interaction，互动）关系。
抽象	抽象是一种“抽离于物体的性质描述”，或一种“只含本质而不含细节的”表述。
复杂的系统	复杂的系统，是由很多高度相关、高度互联或高度混杂的元素或实体所组成的系统。
层次	层次是一种其实体均处在某个层次或某个位阶的系统，这些层次是按照上下顺序排列起来的。
原子部件	把握简单的规则：1）不能拆解的东西都可以叫做原子部件。2）凡是一经拆解就失去意义的东西，都可以称为原子部件。
对象	对象是于某段时间内有可能稳定而无条件存在的事物。
操作数	操作数是一个对象，因而有可能会在某段时间内稳定且无条件地存在。
过程	过程是对象所经历的一种转换模式。过程通常涉及及操作数的创建、销毁或改变。
概念	概念是我们对产品或系统所形成的图景、理念、想法或意象，它把功能映射到形式。它是对系统所做的规划，描述了系统的运作方式。概念虽然不是产品/系统的一项属性，但它却是形式与功能这两项属性之间的一种观念映射。
系统架构	系统架构是概念的体现，是对物理的/信息的功能与形式元素之间的对应情况所做的分配，是对元素之间的关系以及元素周边环境之间的关系所做的定义。
行为	行为是由功能以及功能相关的状态变化情况所构成的序列，系统中的形式对象，应该按照这个顺序来执行各项功能，以便使系统的价值得以体现。

▐ 2.3 原则

原则是持续存在的基本原理，它们一直有效或在绝大部分情况下有效。

原则	解释
涌现	当各实体拼合成一个系统时，实体之间的交互会把功能、行为、性能和其他内在属性涌现出来。我们要思考并试着探寻系统所涌现出的预期属性和意外属性。
整体	每个系统都作为某一个或某些更大系统的一小部分而运作，同时，每个系统中也都包含着更小的一些系统。要整体地思考这些关系，并研发出上级系统、下级系统和平级系统相协调的架构。
聚焦	在任何一个点上，都能发现很多影响系统的问题，而其数量已经超出了人的理解能力。因此，我们必须找出其中最关键、最重要的那些问题，并集中精力思考它们。
价值与架构	价值是有着一定成本的利益。架构是由形式所承载的功能。由于利益要通过功能而体现，同时形式又与成本相关，因此这两个论述之间形成一种特别紧密的联系。研发优秀的架构，就相当于体现适当的价值，优秀的架构是用极简的形式来达成令人满意的功能，而适当的价值则是由极少的成本所创造出来的利益。
解决方案中立	糟糕的系统规范书，总是把人引向预先设定好的某一套具体解决方案、功能或形式上，这可能会令系统架构师的视野变窄，从而不去探索更多的潜在选项。尽量使用与特定解决方案无关的功能及语言结构来描述系统，以便使架构师能够意识到该问题的探索空间其实是相当广阔的。
架构师角色	架构师的职责是解决歧义、专注创新，并简化系统复杂度。架构师致力于创建那种能够体现价值并具备竞争优势的优雅系统，他们要定义系统的目标、功能及边界，要创建出能够融合适当技术的概念，要对功能与形式之间的映射情况进行分配，也要定义接口与体系，并对系统做出抽象，以管理其复杂度。
歧义	系统架构的早期阶段充满了歧义。架构师必须解决这种歧义，以便给架构团队定出目标，并持续更新目标，
遗留元素复用	由人类所构建的系统，都会在概念上或是从物理/信息的意义上，对遗留元素进行复用。要透彻地理解遗留系统及其涌现属性，并在新的架构中把必要的遗留元素包括进来。
产品进化	系统必须进化，否则就会失去竞争力。在进行架构时，应该把系统中较为稳固的部分定义为接口，以便给元素的进化提供便利。对系统的进化情况进行规划时，要由宏观的视野，而且要预留足够的资源。
表面复杂度	现代系统的复杂程度，已经超过了人类的理解能力。因此，我们要对系统进行分解、抽象及分层，将其表面复杂度控制在人类所理解的范围之内。
必备复杂度	系统的必备复杂度取决于它的功能。把系统必须实现的功能仔细描述出来，然后选择一个复杂度最低的概念。
第二定律	系统的实际复杂度总是会超过必备复杂度。架构师要令实际复杂度经理接近必备复杂度，同时又要把表面复杂度控制在人类可以理解的范围之内。
2下1上	要想判断出对 Level 1 所做的分解是否合适，必须在向下分解一层，以确定出 Level 2 中的各种关系。然后对 Level 2 中各元素之间的关系进行分组，并选出一种最能够反映分组情况的方式，来对 Level 1 进行模块化。

▐ 2.4 方法

方法是对达成具体目标所需的手段和任务所做的一种规划方式，它们应该坚实地建立于原则之上。

步骤	系统思维的任务内容
1	确定系统及其形式与功能。
2	确定系统中的实体、实体的形式与功能，以及系统边界和系统所处的环境。
3	找出系统内及系统边界处的那些实体之间所具备的关系，以及那些关系的形式与功能。
4	基于实体的功能以及实体之间的功能互动，来确定系统的涌现属性。预测涌现物有三种方式：1）根据先例来预测，2）做实验，3）建模，此外如果这三种都不合适，那最终必须依靠我们自己的判断力。

▐ 2.5 工具

对复杂的架构所做的描述，包含着巨量的信息，其信息量远远超过了人的理解能力。那么，这些信息应该如何展示才好呢？主要办法有两种。一种是维护一个集成模型，并根据所需要对其进行投射。另一种是在模型中维护多个视图。

▐ 2.6 观点

系统架构的建立过程，既是科学，又是艺术。
架构师应该是专才，而非通才。
架构就是对系统中的实体以及实体之间的关系所进行的抽象描述。
错误的架构可能会毁掉整个项目，而“正确的”架构仅仅是创建了一个产品开发平台，产品可以依赖整个平台取得成功，但也依然有可能失败。
系统思维（system thinking）,简单地说，就是把某个疑问、某种状况或某个难题明确地视为一个系统，也就是视为一组互相关联的实体。
系统同时具备形式与功能这两个特征。形式说的是系统是什么，而功能则说的是系统做什么。
人脑可以同时思考的事情是有限的。一般来说，这个数量是7（左右浮动2个）。
形式是线性的（linear），功能并不是线性的。
系统之所以变复杂，是因为我们对系统总是有“更多的要求”：要求系统有更多的功能、更好的性能，要求系统更加健壮、更加灵活。系统变复杂的另一个原因，在于我们要求系统要能够与其他系统相互协作、相互连接。
复杂系统的四种思考方法：自顶向下（top-down）和自底向上（bottom-up）是细看系统时的两种方向。除了这两种方式外，还有一种方法是同时从顶部和底部向中间进行，这叫做由外向内（outer-in）的思考方式。真正复杂的系统实际上是没有顶和底的，因此，我们在现实工作中总是会使用由向内外（middle-out）的办法，也就是在系统层级中选定一个点，然后试着由该点开始，向上或向下探索 1~2 层。
若想理解系统，就必须先理解系统的结构。
功能与价值总是体现在系统边界的接口处。
架构并不是一项独立属性，而是形式与功能之间的映射。
一个工具只对应一个过程且一个过程只对应一个工具的这种简单模型，显然是无法推广的。
要把观念扩展为功能架构，首先要确定系统在体现其主要价值时所依循的价值通路。

▐ 2.7 总结

形式，功能与概念，构建了产品架构分析要素的铁三角，这些名词也出现在我们日常需求、编码、讨论等一系列的活动中，值得大家关注。

理解架构要素 — “概念”

最近看了《软件设计的要素》这本书，感觉很有意思。正所谓“虚的事情实着做，实的东西虚着做”，本书通过大量的产品分析案例，来解释“概念”这个比较虚的名词，让人印象深刻。同时，我们日常的很多架构活动，就是通过用例枚举和推演，去厘清“概念”，推进关系的合理建模。所以“概念”这个名词，值得理解和探讨一下。

▐ 3.1 暴论：概念为王

3.1.1 概念“包袱”

软件开发过程中，大家往往需要处理很多复杂的历史包袱。有时候，如果往"CURD"的层面看，可能很直接简单，但可能已有实现中有很多前人的设计和概念，这里理念被大家引用，但并不成熟，会让我们的设计充满约束和负担，非常困难。

难就难在，我们很容易使用“无设计” 或者“延续设计”的策略，因为这两种都可能会走向2个极端：一个是完全否定之前的建设，提出自己更加不成熟的理论；一个是在之前不合适的道路上越走越深，深陷泥潭。这时候，往往唯一的出路是提出一个更加合理的理论，包容之前建设，同时将未来的建设引向一个更易理解和操作的实操上去。但一些“理念”如果没有日常的积累，要在短时间内想清楚，会很难。

3.1.2 “概念为王”

此外，我们有很多的架构活动，都会在研究业务活动的过程中，提出一些“概念”，期望用这些概念去串联关键的链路，形成收敛的思考阵地。

这些事情，让我感觉到，程序员的意识、判断、设计等，的确会对大家的软件开发过程形成影响，无论这个影响是正向的，还是负向的。而且系统越大，人员越复杂，这个影响越深刻。所以，我们得重视“概念”的生产和使用，不能让概念“随意”地就能生产出来，要增加其被采纳的门槛，也就是得有更频繁、广泛的讨论，要有更长远和深度的思考。

在上面的思考之后，隐约感觉到需要为上面的认识定性，到底背后的信仰、认识出发点是什么，所以提出“概念为王”的口号。恰好最近看到一本《软件设计的要素》的书，里面提到概念的重要性，而作者也是非常权威的教授和行业专家。我突然意识到，“概念为王” 在技术信仰之外，还可以得到理论的支持，于是大胆地提出了这个暴论。

3.1.3 概念的影响

在“概念为王”的口号下，我觉得最受益的必然是领导层和为领导服务的“秘书”（架构师、小组长、横向人员等）。因为，本身他们的事情和具体事情就有一层说不清的“隔膜”，“看似相关，看似无关”，让人觉得模糊和微妙。但是在“概念为王”的口号下，这些虚的部分，往往是概念价值链生产的必要组成部分，一层层渐渐加工，最终流转到生产一线，产生影响。

“概念为王”的背后，我们其实还是在探索事情的本质，用“抓住主要矛盾，给关键方向定调”的方式，来确定一些比较长远的认知模式，减少一线的重复和反复。这可能是“概念”真正的价值：它就像一面旗帜，当它立起来的时候，大家只要去思考找反例，而不是先思考立什么旗，效率一下子提升了。

3.1.4 概念的延续

在这个背后，“概念”的延续性的确是个很微妙的话题。一朝天子一朝臣，做事情的人不一样，就很容易“忘记”、“产生新的想法”，让事情不停表现出各种理解版本，各种实现分支。这背后，可能希望组织有长期保留人才的能力，同时能通过日常的讨论，让团队文化一脉相承。

探究概念的本质并信任这个事情，可能能够让大家的工作更加有成就感，更能明白自己并非一颗冰冷的螺丝钉，而是一个有温度的、思考的生命体。

▐ 3.2 书中的概念理论

3.2.1 概念历史和定义

在作者的序中提到：

概念模型是软件核心的想法可以追溯到20世纪80年代以用户为中心的计算模型的出现。

在那个时代，特别有影响力的还有《日常事务的设计》，其中心思想是机器（无论是不是软件）用户的心智模型必须与设计师的心智模型一致，因为后者的心智模型代表了机器的实际运作方式。

在我的书中，我提出了一个简单而灵活的概念定义：概念是一种独立的服务，由状态和操作组成，它能实现用户的目的。

个人共鸣：

我们虽然常喊“客户第一”的口号，但是却不知道如何做到，各种设计以用户为中心，站在用户的角度去理解，可能是最关键的一步。
站在用户角度去思考概念的原始合理性，这个非常重要。有时候我们会基于产品方案，大家实现去做抽象，但是这个如果已经偏离方向的话，只会越走越远。
概念这么抽象的定义，都和经典的“属性”+“行为”模型定义类似，可见我们要解释一个东西，既要描述它有什么，还要描述其操作能力，这些都是必不可少的。没有纯粹的概念，不被使用，就无法确定其内涵。

3.2.2 概念价值与可研究性

作者认为，概念概念会影响设计，进而影响软件的成功，概念应该被研究和完善，是有理论存在的。

为什么有些设计如此成功，而另一些却如此失败？

我们对软件的设计缺乏敬意和认知，是由于我们关于软件可用性的想法更多地基于不可靠的经验，而不是基于丰富的理论。我希望通过本书能证明这样的理论确实存在，并鼓励他人进一步发展和完善这些理论。

个人共鸣：

我们总是在产品现有的功能上做加法（比如：电商的营销玩法），却很少思考已有功能的关系，为什么要这么做。如果基于客户的原始理论能够逐步完善，被更多的高层认可，那么我们的产品的易用性，产品的专业性，客户的满意度都会有很大的提升。

3.2.3 如何研究概念

概念如此抽象，作者该如何介绍，这是我在看这本书前的很大一个疑惑，所以我觉得本书的目录结构也很有参考意义。

概念，设计引爆与出圈的核心

概念就像分子，成功的软件不可或缺
掌握概念起作用的原则，做出更好的设计

概念与要素，系统构建起成功软件的框架

概念的结构，从样式概念到预订概念
概念的目的，以用户需求为中心
概念的组合，早就意向不到的力量
概念的关系，让设计的顺序更合理
概念的映射，从底层概念到物理界面

谨记概念的原则，让好设计源源不断

概念的特性，概念与目的一一对应
概念熟悉性，好用的概念常常可以重用
概念完整性，一旦违反需要努力修复

个人共鸣：

这些分析的原则是比较朴素的，过程中，最惊叹的是作者用我们熟知的软件产品进行了大量举例，通过足够度多的案例去论证这些观点。以至于到最后，我都觉得这些理论已经不那么重要了，具备作者这种细致分析，以客户理解为出发点的研究精神才更重要。

3.2.4 概念关键模型

概念的定义

概念的名称 concept
概念的目的 purpose
概念状态 state
概念操作 actions
操作原则 operational principle

概念的组合案例

产品概念案例

2.2.5 “金句”理解概念

如果软件设计有错误，无论做多少消除缺陷的工作都无法修复整个系统，除非回到最初修复设计本身。
设计思维可以独立于任何特定领域，这可能是其具有广泛吸引力和适用性的关键，但这也是它对软件设计这种特定领域的深层挑战没有任何洞见的原因。
逻辑本身并不重要，重要的是它们的使用难度。
软件设计是我们都想讨论的话题，但我们还不知道如何进行讨论。
概念就像是分子：虽然互相结合在一起，但无论在哪里出现，它们的属性和行为都是相似的。
在编程中，抽象（abstraction）和表达（representation）有着重要的区别，抽象是抓住编程的本质，也可能用于对观测到的行为进行说明。而表达是通过代码实现这个本质。
概念本身即是用户想要的心智模型，也是软件的规格。
虽然投资核心概念这件事听起来没有那么花哨，但可能更有效。
概念能将功能更清晰地划分为独立的单元，每个功能单元都有自己的价值和成本。
我认为在软件设计中，解决问题最重要的策略是分离关注点，即分开处理关注点的不同方面，即使有些关注点并不完全独立的。
人们更多地关注用户界面如何忠实和有效地体现概念模型，而不关注概念模型本身的结构。
仅仅知道为什么要设计软件也是不够的，你还需要为设计中的每个概念找到目的。
尤其是在软件设计方面，由于它有无限的复杂性，人们很容易陷入细节并失去对大局的把控。这时候要想想最初的目的，后退一步并重新定位问题。
概念应该是独立的，可被独立理解，并在不同场景中被重复使用。
一个概念最多只能满足一个目的。专一已被证明是概念设计中最有用的原则之一。

▐ 3.3 总结

常听说，国外做“工具”靠信仰，不需要回答价值，价值是显而易见的。这和ToC产品要“网络规模”的逻辑是一样的，一次次被证明过，就不需要解释了。我想未来有一天，概念的理解和讨论会更加频繁地发生，以消费者视角为中心的概念定义，需要投资，也应该被认可，不需要回答价值。

行业 - 银行业架构网络 BIAN

官方网站地址：https://bian.org/

▐ 4.1 序

BIAN 介绍

金融服务业架构网络（即BIAN）是一个由银行、解决方案提供商、咨询公司、集成商和学术合作机构组成的全球非营利性组织，其共同目标是为金融服务业定义语义标准，涵盖几乎所有众所周知的架构层。

达尔文理论

能够生存下来的并不是最强的物种，也不是最智能的物种，而是最能适应变化的物种。—— 查尔斯·达尔文

“It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change” - Charles Darwin

敏捷性

敏捷性是一个实体的持续行为或能力，它表现出灵活性，可以快速适应预期或意外的变化，遵循最短的时间跨度，并在动态环境中使用经济、简单和优质的工具。

敏捷性的三个主要领域

系统敏捷性：组织运营（业务和ICT运营）的敏捷性。
流程敏捷性：在开发和变更过程中保持敏捷。
业务敏捷性：基于金融机构的流程和系统敏捷性，将敏捷性作为战略重点。

▐ 4.2 敏捷架构原则

关注点分离：复杂的系统可以拆解为一些基本且不重复的责任集合。这些责任领域可以分层（分层是指战略、业务、应用、数据和技术职责的分离）并基于能力（组织、个人或系统拥有的能力）进行定义。这些能力就是将功能集中于其中的组件。
松耦合：由分离关注点识别出来的组件，如果它们之间的依赖数量较少，它们就是松耦合的。每个组件都将通过提供服务来履行其职责，且对其他组件服务的依赖最小。功能和数据具有高度的内聚性，这有助于分析和理解组件自身。
可重用性：如果组件可以在多种情况下使用，并且独立于端到端流程的状态，则他们是可重用的。独立性和可重用性是组件设计的目标，这是一个战略选择，它要求对组件的连接使用通用标准，例如通用词汇表、通用数据、通用服务定义和通用文档结构。
可封装性：如果组件都有自己的内部数据结构和流程定义来实现其所提供的服务，则组件是可封装的。组件的服务通过明确定义的接口提供给环境，这些接口从服务请求者的易用性角度出发，隐藏了其内部复杂性。
互操作性：组件间交换信息和功能服务，就好像组件之间没有边界一样。一个信息系统、业务功能或其他元素通过使用基于明确定义的接口标准连接到其余架构图景的部分，并通过指定服务级别协议（service level arrangement，SLA）的契约进行设计。因此，新的或变更的业务流程都可以编排组装此类组件。
面向服务：组件相互间提供服务。业务职能部门提供并使用内部和/或外部业务服务。不允许直接访问数据，必须通过服务发起请求。

▐ 4.3 架构思维

BIAN 协会的目标是解决一个关键问题：为什么 BIAN 模型和方法在解决应用组合和互操作性复杂性方面比其他模型和方法更能成功？

BIAN 协会的核心主张是采用以能力为导向的方法来架构并支持金融机构的业务和ICT系统。这种方法与流行的“以流程为中心”的设计思路有着根本不同。

任何架构和设计都结合了两个视角：架构要基于的要素和架构要支持的行为。要素同要部署的静态或持久物相关，而行为是对预期事件或触发器触发所期望得到的响应，其具有更动态的模式。一个架构师需要理解如何配置要素以支持预期行为，并基于此做整体设计。

BIAN 标准的功能分区定义了相互离散的不重合的功能。BIAN 服务图景旨在确定可能构成任何银行的所有可能的基本业务功能。使用 BIAN 分区组装的银行蓝图创建了与城市规划相同的架构蓝图 - 消除了构建块的重合并定义了它们之间的标准连接。

▐ 4.4 BIAN 元模型

BIAN 元模型概览

元素	语义定义
动作术语	描述服务操作目的的基本行为单位
API Swagger 文件	一种机器可读的格式（根据语义API 描述的 Swagger）
资产类型	银行拥有所有权和/或影响力，可以为银行创造价值的有形或无形物品。
行为限定符	一组用于限定（即精化）服务域的控制记录的业务信息
行为限定符类型	一种用于优化通用工件并提供行为限定符分类的信息类型
业务领域	一组业务域，用于结构化地呈现服务图景
业务能力	企业为实现特定目的而可能拥有或交换的特定能力
业务域	一组服务域，用于结构化地呈现服务图景
业务对象	存在于现实中具体或抽象的事务，参与和/或影响业务的本质
业务场景	服务域之间为响应业务事件而进行的交互连接时序
控制记录	一组业务信息，为支持在资产类型实例上履行服务域角色所需的所有信息
功能模式	在执行商业业务时可以应用于某些资产的行为或机制
通用工件	由符合功能模式的任何服务域生成和/或管理的工件的通用类型
消息	通过语义 API 端点交换的输入和输出参数
语义 API	一个服务域的语义 API 端点的集合
语义 API 端点	一个服务域对外提供的一个服务操作的访问端点
服务域	能够以服务方式对外提供能力的离散且独特的业务职责，是一种基本或原子的功能构建块
服务操作	由服务域暴露的业务服务
连线图	表示一组选定服务域之间可用的服务连接的交互

注：BIAN 没有将特定的业务领域和业务域定义为规范标准，因为不可能强制所有银行对业务功能进行特定的层次化分解。

▐ 4.5 BIAN 能做什么

通用能力 — 作为参考架构

通用词汇
通用参考框架：解决方案的功能可映射到BIAN 服务域来描述。
组织和利用文档：使用 BIAN 制品作为架构和解决方案索引文档。
参考架构的构建块：有助于识别做什么、在哪里、由谁完成等。

用于整体企业视图

战略业务能力
服务域用于架构
构建企业蓝图
统一稳定的绩效管理基础
用于投资和变更组合管理

用于业务层

绘制和评估业务图景
治理业务架构
支持并购
业务变更组合
用于业务流程管理
用于业务需求分析

用于应用层

实用程序与服务域对比
应用架构治理
端到端的解决方案架构
创建“系统”
应用架构风格

用于信息和数据

商业智能 BI 环境辅助
用于信息分类
与数据技术的链接

经验 - 运用最小企业架构构建业务平台

本节是对丁杰老师在ArchSummit全球架构师峰上的分享《运用最小企业架构构建业务平台》的学习笔记。相关会议和 PPT 下载可以进入地址：https://archsummit.infoq.cn/2024/shenzhen/schedule

▐ 5.1 令人失望的平台

业务平台的存在需要回答两个主要的话题：

1）业务平台应该承载什么能力、发挥什么价值？

挑战：系统功能并没有改变甚至减少，为什么要改造，价值是什么？

2）运用企业架构的建设过程如何更加轻量和敏捷？

挑战：追求逻辑的完备性，需要大量梳理过程，过程缓慢；陷入争议难有定论；需求越滚越大

▐ 5.2 业务平台的价值

假设改造了十个系统，可以叫10个系统，也可以叫10个平台，“系统”还是“平台”名字并没有本身的意义和价值。“平台化”要回答发生了什么变化？

类比“造车”，原来传统车企主要是单一链路的建设，线性的产业链，主要竞争手段是不断去管控上下游，掌握更加重要的资源。互联网造车新势力，则发挥了人、车、家的网络协同价值，不仅车本身带来价值，新的交互和互联可能，带来了更多的价值链，发挥的是协同效应。

相应的企业架构，或者说业务平台的建设，还是为了让企业中的各种要素联通起来，发货出1+1>2的积极效应。如果各自系统各自为政，并没有发挥大家的合力。企业架构应该建立机制、规则，让要素间产生协同效应。所以回答 “业务平台应该承载什么能力、发挥什么价值？”，就是带来积极的网络效应。

▐ 5.3 架构活动如何更加敏捷

业务平台的积极网络效应能带来规模化的成效，也会带来规模化的复杂。同时在考虑业务架构的时候如果要映射到IT架构上，那么细节的牵绊，会让整个过程非常缓慢，范围也难以控制，容易膨胀失控。

业务平台建设轻量化、敏捷化的有效举措是将商业决策与IT设计决策分离。也就是说关注点分离。

商业决策要关注要解决什么问题，解决到什么程度。这些问题往往不是突然冒出来的，而是一以贯之的，只是现阶段要解决的程度更深一点。确定重点问题是什么，避免过早陷入流程细节中。
IT设计决策要基于用户驱动，也就是要通过更多用户触达、快速的响应，贴近用户场景、有重点、有阶段地解决。不应该过于追求大而全的完美解法。

整个过程，关注这些点：

价值流：平台需要构建哪些价值网络；
业务能力：平台需要增强什么能力、到什么程度，完成价值交付；
业务对象：平台价值的载体；
组织架构：谁负责能力的构建或使用，权、责、利边界是怎样的；
应用系统：业务能力由哪些IT系统提供；
以变革管理的运作模式推进业务平台的有序建设。

▐ 5.4 总结

在看丁杰老师的分享的时候，个人深刻感受到：整个思想，可以类比为“大模型的裁剪”。大而完备的大模型是很消耗资源的，但是我们可能只是需要解决特定领域、比较垂直的问题，比如：教育场景、医疗场景等垂直领域。那么我们的架构活动也类似，为了追求更好的收益，就应该放弃追求完美，转而追求解决主要矛盾，在特定问题域解决问题。

缩小问题域的同时，我们应该有一些比较成熟的实施过程参考、交付物模版等，来提升交付效率。也要加强用户反馈收集，让结果更加符合用户预期。

这里面可能还有一个反复提到点是，理论讨论应该有个度，不应该过渡追求逻辑，通俗地讲，“「为什么」不那么重要，能「意会」到就可以了，「解决实际问题」才比较重要”。比如：陷入L3 和 L4 的边界和粒度讨论，一定要给出答案，可能已经脱离了实际场景的意义，它本身只是一个分层，不同场景粒度也不一样。

认知

这部分比较杂，但是也是架构师的关键认知的重要组成部分。

▐ 6.1 程序员的底层思维

本节是对《程序员的底层思维》这本书的读书笔记。令人惊叹的是：作者有非常大的阅读量，单单里面提到的书名，都可以成为长长的推荐书单。

提到书籍：《逻辑学导论》、《深度思考法》、《学会提问》、《快思慢想》、《金字塔原理》、《奇妙的数字7±2》、《选择的悖论》、《软件架构》、《设计模式解析》、《面向对象分析与设计》、《架构真经》、《必然》、《简单法则：设计、技术、商务、生活的完美融合》、《箴言书注》、《终身成长：重新定义成功的思维模式》、《刻意练习：如何从新手到大师》、《系统架构：复杂系统的产品设计与开发》、《淘宝十年产品事》。

下面是文中的笔记：

认知的4个层次，从低到高依次是“不知道自己不知道，知道自己不知道，知道自己知道，不知道自己知道”。
面向对象（Object Orirnted，OO）技术实际上由3个部分组成，分别是面向对象分析（Object Orirnted Analysis，OOA）、面向对象设计（Object Orirnted Design，OOD）和面向对象编程（Object Orirnted Programming，OOP）。
逻辑是指思维的规律和规则。
我建议，任何领域都应该有一份核心领域词汇表，方便团队在这些核心概念的表达和命名上达成共识。
在管理学中，有一个著名的模型叫做罗伯特卡茨模型，其中提出管理者必须具备3种必要的技能，分别是技术技能（Technical Skill）、人际关系技能（Human Skill）和概念技能（Conceptial Skill）。
判断是概念的展开，没有判断，就不能揭示和说明概念。同时，判断也是推理的前提，是正确运用各种推理的必要条件。
5So 思考法，是指对一个现象连续追问其产生的结果，以探索它对未来可能造成的深远影响。
人类都是主观性的动物，别说客观公正了，很多时候，连理性都没有，都是感觉直观。
所谓结构化思维，就是从无序到有序的一种思考过程，将搜集到的信息、数据、知识等素材按照一定的逻辑进行分析和整理，呈现出有序的结构，继而化繁为简。
人类大脑在处理信息的时候，有两个特点：第一，不能一次处理太多信息；第二，喜欢有规律的信息。
MECE 原则：各部分之间互相独立（mutually exclusive），没有重叠，有排他性；所有部分完全穷尽（collectively exhaustive）。
一些模型：制定市场营销策略的“4P”模型；思考组织战略的“7S”模型；分析竞争力的 SWOT 模型；制定目标的 SMART 模型。
中台的底层逻辑，用一句话解释就是通过复用提升研发效率。
业务中台低效的根本原因在于，前台业务和业务中台的“深度单体耦合”。
在我的职业生涯中，我看到很多业务技术部门都尝试设立技术架构组织，基本都以失败告终。
很多后劲不足的人主要是过早地停止了学习和成长，你的能力应该是围绕着你的层级上下震荡的，这个震荡范围偏差不会太大。
不管你们有多敬业、加多少班，在面对烂系统时，你仍然会寸步难行，因为你大部分的精力不是在开发需求，而是在应对混乱。
雷军说过，永远不要视图用战术上的勤奋，去掩盖你战略上的懒惰。
不要把自信建立在贬低他人的基础上，什么时候你能发自内心地欣赏你不喜欢的人，你就成长了。
如果只能选一个思维工具，那么这个工具应该非“矩阵分析”莫属。
用户分群模型 RFM 模型：依托于用户最近消费时间（Recency，R）、消费频率（Frequency，F）、消费金额（Monetary，M）3个维度进行评估。
阿里巴巴用人准则是“捧明星、杀野狗、清白兔、用黄牛”，其背后的逻辑就是矩阵分析中的“九宫格人才盘点法”。
设计就是分类。 —— “微信之父” 张小龙
所谓共性，本质上就是对象之间的交集。这个交集要么是共同的属性，要么是共同的行为。
我们将对象定义为有清晰定义的边界的事物。但是，将一个对象与其他对象分开来的边界常常非常模糊。
我强烈建议不要引入笨重的流程引擎，凭空为应用增加很多不必要的复杂度。简单的 Pipeline 是解决此类分治问题的最佳选择。
把一件事情搞复杂是一件简单的事情，但要把一件复杂的事情变简单，这是一件复杂的事。
SHE 简化法则——S 是 Shrink (压缩)，H 是 Hide（隐藏），E 是 Embody（赋予）。
奥卡姆剃刀原理，是指如无必要，勿增实体（Entities should not be multiplied unnecessarily），即“简单有效原理”。
只有一条路不能选择，那就是放弃的路；只有一条路不能拒绝，那就是成长的路。
任何能帮助你更好理解现实世界的理论框架，都可以称之为思维模型。
领域模型是对领域内的概念类或现实世界中对象的可视化表示。
“有数据呈现数据，没有数据呈现案例，没有案例呈现观点，如果都没有的话，就请闭嘴”。
在践行 DDD 的过程中，有一个问题一直困扰着我：哪些能力应该放在 Domain 层？是不是应该按照传统的做法，将所有的业务都收拢到 Domain 层？这样做合理吗？

个人总结：

我们日常的思维策略，都可以聚少成多，写出那么厚重的一本书，可见世上无难事，只怕有心人。

▐ 6.2 P9 工作法

最近读了《P9 工作法》这本书，里面主要讲了技术关键点、架构思考、技术领导力理解这三方面。文字中不仅仅讲成功经验，也将其中的局限、限制、误区等很朴实的点分享出来，值得一看。本节就是其中一些比较有感觉句子的简要笔记。

理解问题，适当抽象问题背后的模型，结合专业技巧，在简洁中寻求平衡，并能随问题的发展不断演进，这是好代码的第三个阶段。
代码重构其实是一种技术投资，投入时间和资源以优化代码，从而获得支持业务发展的收益。
领域模型包含三个核心要素：目标、实体和关系。
如果实体没有包含六大要素，那它大概率就是坏的，这六大要素包括属性、行为、状态机、完整性检查、平衡性检查、以及和核心逻辑计算。
从问题出发，收集信息：明确问题、描述问题、定义信息、统一信息、还原问题。
在抽象模型的过程中，需要遵循“如无必要，勿增实体”。
“手里拿着锤子的人，看什么都是钉子”。对于一些知识流程编排类的系统，如门户系统，其职责主要是聚合各个业务领域的服务并呈现给用户，并不适合使用领域模型。
曾经让你成功的要素可能会成为再次进步的障碍：

第一，未来的不确定性。由于无法准确预测未来业务问题的本质，因此不敢轻易升级模型。
第二，升级到新模型会导致对老模型的改造工作量巨大。

开会需要避免“有会无议，有议无决”。
对技术架构师的理解为：运用技术架构的思维框架深入分析业务需求，识别关键问题，并通过持续的演进和迭代来提升系统能力，以支持业务实现商业成功。
VUCA：即Volatile（易变）、Uncertain（不确定）、Complex（复杂）、Ambiguous（模糊），可能是对这个世界最好的描述。
架构的局限早已注定，架构的本质是建模客观世界以解决现实问题。然而，客观世界具有两个关键特征：

未来具有巨大的不确定性。
历史虽然可信，但未必可靠。

架构应该力求做到恰如其分，即不追求完美，但必须符合商业逻辑。为了实现这一点，架构需要具备以下三个特征：

看三年做一年。
适度小马拉大车。
具有经营性思维。

俗话说：“骂着众，献策者寡，行动者无几”。
“没有发展才是最大的风险”。
架构回答不了的问题有：

架构回答不了唯心的问题。
架构回答不了决策性问题。
架构回答不了生产关系问题。

战略即做出选择。“战略”一词，拆分开来，包含“战”和“略”两个方面。“战”指的是明确目标，“略”则是找到关键点。
技术架构的恒定底色在于：解决同类业务问题的效能和成本是否具有边际效益，是否能够以最低成本复用现有能力快速解决类似业务问题，以及风险是否能够通过有效措施和保障得到控制。简而言之，技术架构是否具备成本、效能和风险的优势，并能够提升商业竞争力。
“上医治未病、中医治欲病、下医治己病”。
回到根本：找到实际与预期的偏差。找到实际，找到预期，就能找到偏差。分析影响偏差的因子，就能找到原因和动作。
有了能力树之后，任何都可以找到实际和理论的差距，明确从当前状态到目标状态的路径。
一旦有了明确的位置，架构就有了存在的意义。
一个好的模型必须要有思想，其背后可以基于会计理论，层次化的架构模型，或者多因子的数学公式。任何科学定律、数学定理都可以被认为是最好的模型，也是真正的逻辑。
“七见模型”：

一见位置
二见问题
三见解法
四见逻辑
五见概念
六见故事
七见价值

架构的三重挑战：

从繁到简，可以理解为问题已经清楚，解法也有，但逻辑不清，异常复杂。
从虚到实，可以理解为问题清楚，但是解法不明确。

从无到有，可以理解为问题本身就不清楚。

做架构，应努力形成专业理论，并撰写白皮书。只有这样才能够全面深入地理解问题，使工作更有条理和章法，不能靠运气。
着眼难处，着手简处
将原则内化为逻辑：将原则直接嵌入代码中，让机器来传承，是一种务实和可靠的方法。
架构白皮书是对技术架构的全面阐述，包括架构的设计理念、原则、决策过程、演进历史、当前状态和未来规划。
技术架构师的三项主要职责：

军师：助力业务赢得市场
法官：理性建立架构秩序
巡警：风险自查效率为先

识别关键点：

一旦形成后期改造成本巨大的即为关键点。
生产环境故障对业务影响巨大的即为关键点。
项目中方案频繁变更或进展缓慢的即为关键点。
项目中实现的关键技术目标即为关键点。

没有业务成功，就没有技术先进性。
在全局中求高度，在细节中求深度，在极简中求锐度。

附录

《现代企业架构框架》
Thoughtworks为适应企业现代化需求，开发了《现代企业架构框架》欢迎查阅关于IT设计决策方面的企业架构实践。
《丁杰-运用最小企业架构构建业务平台》PPT：https://archsummit.infoq.cn/2024/shenzhen/schedule