需求与设计 on 雪狼的书斋

1.设计思维与业务理解

Mon, 01 Jan 0001 00:00:00 +0000

领域驱动设计（Domain-Driven Design, DDD）被誉为构建复杂业务系统的「圣经」。它强调将软件设计与核心业务领域深度融合，通过构建精良的领域模型来解决复杂的业务问题。

然而，在着手领域建模之前，我们常常会遇到一个根本性的挑战：我们真的理解业务问题吗？ 客户或产品经理给出的，常常是他们「认为」的解决方案（「我需要一个能过滤订单的下拉框」），而非其背后的深层业务问题（「运营人员筛选订单效率低下」）。

这篇文章，雪狼将为你揭示设计思维（Design Thinking），这个以人为本的创新方法论，如何成为 DDD 的前置步骤，帮助架构师拨开「伪需求」的迷雾，直抵业务本质，为后续的领域建模打下最坚实的基础。

挑战：「解决方案」伪装成「问题」#

场景再现：业务方急切地要求：「我们需要在首页显示一个排行榜，来刺激用户活跃！」
隐藏的问题：真正的业务痛点可能是「用户活跃度持续下降，需要新的激励手段」，而排行榜只是业务方想到的一个解决方案。
潜在风险：如果架构师直接实现「排行榜」这个解决方案，而没有深入挖掘背后的问题，很可能做出来的排行榜效果不佳，甚至浪费了宝贵的研发资源。

设计思维：架构师的「共情引擎」#

设计思维是一种以人为本的解决问题的方法论。它通过一系列迭代的步骤，帮助我们从用户的角度理解问题，从而找到创新且有效的解决方案。

设计思维的五大核心阶段：

共情 (Empathize)：深入理解用户、他们的需求、行为和痛点。
定义 (Define)：从用户的角度，清晰地定义问题。
构思 (Ideate)：发散性思维，产生尽可能多的解决方案。
原型 (Prototype)：快速构建低成本原型，将想法具象化。
测试 (Test)：用原型与用户互动，收集反馈，验证假设。

设计思维：DDD 的「前置引擎」#

设计思维的整个流程，都为 DDD 提供了不可或缺的输入和验证。

1. 共情 -> 深度理解领域#

设计思维目标：通过用户访谈、观察等方式，沉浸到用户场景中，理解他们的真实痛点。
DDD 关联：这直接帮助架构师和领域专家识别核心业务领域、子域，并开始构建「统一语言」（Ubiquitous Language）的词汇表。它揭示了领域模型需要解决的「真实问题」。

2. 定义 -> 精准定位问题#

设计思维目标：从用户的视角，清晰、准确地定义要解决的「问题声明」。
DDD 关联：这帮助我们聚焦核心业务目标，从而更好地识别 DDD 中的「限界上下文」（Bounded Contexts）和领域模型的核心范围。它将模糊的需求转化为清晰的、可建模的问题。

3. 构思 -> 探索解决方案空间#

设计思维目标：在明确问题后，发散性地思考多种可能的解决方案。
DDD 关联：在明确了核心问题和领域后，这个阶段可以帮助我们探索不同的领域建模方式，识别潜在的领域事件（Domain Events）、命令（Commands）和聚合（Aggregates）。

4. 原型与测试 -> 验证领域假设#

设计思维目标：通过快速构建低成本原型，与用户互动，收集反馈，验证解决方案的有效性。
DDD 关联：这不仅能验证 UI/UX 的可行性，更重要的是，它能验证我们对领域模型关键假设的准确性。例如，通过原型测试，我们可以发现用户对某个业务概念的理解与我们预期的不同，从而及时修正领域模型。

设计思维如何提升架构师的业务理解能力？#

阐明业务全貌：帮助架构师跳出局部功能，从宏观上理解业务的价值流、核心能力和用户旅程。

2.为什么程序员要学习设计思维？

Mon, 01 Jan 0001 00:00:00 +0000

「我只是个程序员，我只负责把需求实现。」

这种观念，在今天这个快速变化、用户体验至上的时代，已经显得越来越陈旧和局限。我们常常抱怨需求不明确、产品逻辑不自洽、业务方朝令夕改。但我们是否也曾反思，自己是否错过了在更早期介入，从根本上影响和塑造产品的机会？

设计思维（Design Thinking），这套以人为本的创新方法论，长期以来被认为是设计师和产品经理的专属武器。然而，雪狼要告诉你，它更是程序员，特别是希望从「代码实现者」成长为「问题解决者」和「产品创造者」的程序员，不可或缺的「超能力」。

程序员的传统角色 vs. 现实困境#

传统角色：被动地接收需求，然后转换为代码。关注「如何实现」，而非「为何实现」。
现实困境：
- 需求歧义：需求文档往往是模糊的，充满了可以有多种解读的表述。
- 「伪需求」泛滥：业务方提出的，常常是他们自认为的「解决方案」，而非真正的业务问题。
- 反复返工：因误解需求或解决错了问题，导致大量代码被推翻重写。
- 缺乏成就感：感觉自己只是个「代码机器」，无法影响产品的走向。

设计思维：程序员的「超能力」#

设计思维不仅仅是工具或流程，它是一种心智模式的转变。它培养我们共情、质疑、发散、收敛、快速验证的能力。

1. 更好地理解业务需求 —— 告别「盲人摸象」#

超能力：设计思维的核心是共情（Empathize）。它教会程序员如何深入用户的场景，倾听他们的声音，理解他们的行为、痛点和未被满足的需求。
影响：
- 提高沟通效率：当程序员能站在业务方的角度思考时，双方的对话不再鸡同鸭讲。
- 减少误解：程序员对需求的理解不再停留在字面，而是深入到业务本质。
- 控制业务复杂度：能够更早地识别需求中的冗余和非必要复杂性，并在技术实现前进行裁剪。

2. 更有创造性地解决问题 —— 从「实现者」到「创新者」#

超能力：设计思维鼓励构思（Ideate），跳出思维定势，发散性地思考多种可能的解决方案。
影响：
- 构建更贴近用户需求的软件：程序员不再仅仅是根据给定方案实现，而是能从技术角度提出创新的解决方案。
- 用更低的成本满足用户需求：技术专家可以在设计初期就识别技术可行性和成本，并引导业务方选择更具成本效益的实现路径。
- 突破技术局限：将技术能力转化为解决业务问题的创意。

3. 提升跨团队协作效率 —— 消除「巴别塔」#

超能力：设计思维提供了一套跨学科团队通用的语言和工作流。
影响：
- 建立共同上下文：程序员可以积极参与到设计思维工作坊中，与设计师、产品经理共同构建对产品的理解。
- 培养默契：通过共创，团队成员对产品目标、用户痛点、解决方案形成一致的心理模型。
- 加速反馈循环：程序员可以利用自己的技术能力，快速构建原型，提供技术验证，加速设计迭代。

4. 为领域驱动设计（DDD）打下坚实基础 —— 深入业务本质#

超能力：设计思维强调对业务本质的理解和对核心概念的定义。
影响：
- 识别核心领域对象：帮助程序员准确识别业务中的核心名词、动词和规则，这些都是领域建模的关键要素。
- 构建更真实的领域模型：确保领域模型能够准确反映业务现实，为后续的代码实现提供坚实、可信的指导。

结语#

程序员不应该满足于做一个「代码机器」。我们身处产品创造的最前线，拥有将想法变为现实的独特能力。

学习设计思维，就是为我们的「技术之手」安上一个「智慧之脑」。它能帮助我们从被动的「需求接收者」，转变为主动的「问题解决者」和「产品共创者」。它让我们能够超越代码，看到技术背后的人性与价值。

告别「闷头写代码」的时代，拥抱「设计思维」这股超能力，成为一名真正能理解业务、解决真问题的「全栈创作者」吧！

3.设计思维的核心

Mon, 01 Jan 0001 00:00:00 +0000

在软件开发的世界里，我们常常沉浸于技术的浩瀚：最新的框架、最快的算法、最酷炫的架构。然而，在追逐技术高峰的路上，我们很容易忘记一个最根本的问题：我们所构建的一切，最终都是为了服务于人。

设计思维（Design Thinking），正是一门将「人」置于问题解决核心的方法论。它不仅仅是一套工具或流程，更是一种根植于人类本能的思考方式。它帮助我们跳出技术和业务的局限，以同理心去理解用户的真实需求，从而创造出真正有价值、被用户热爱、并能带来商业成功的创新产品。

这篇文章，雪狼将带你深入设计思维的核心，理解其「以人为本」的解决之道。

超越技术：以人为本的解决之道#

技术导向的陷阱：我们常常基于对技术可行性的判断，或者对某种技术的偏爱，来构建解决方案。最终可能造出「技术上完美，但用户无人问津」的产品。
设计思维的洞察：真正的创新，始于对人的深刻理解。它强调发现用户未被满足的需求，而不是盲目实现用户提出的解决方案。
核心信念：所有的商业价值和社会影响，都源于对人类需求的有效满足。

设计思维的五大核心阶段#

设计思维是一个非线性的、迭代的循环过程。它通过以下五个阶段，帮助团队从「以产品为中心」转向「以用户为中心」。

1. 共情 (Empathize) —— 深度理解你的用户#

目标：放下自己的经验和偏见，真正地走进用户的世界，感受他们的感受。
实践：用户访谈、行为观察、田野调查、创建用户画像（Persona）和同理心地图（Empathy Map）。
意义：这是设计思维的起点，也是最关键的一步。它帮助我们发现用户的痛点、未被言说的需求和行为背后的动机。

2. 定义 (Define) —— 清晰地定义问题#

目标：从用户的视角，清晰、准确地定义一个可解决的「问题声明」。这个声明应该聚焦于用户的核心需求，而不是团队已有的解决方案。
实践：将共情阶段收集到的信息进行整理、分析，找出核心的、未被满足的用户需求。将问题重新框定为「我们如何才能帮助用户实现 X？」（How Might We…?）。
意义：一个被清晰定义的问题，本身就包含了解决方案的一半。

3. 构思 (Ideate) —— 发散性思维，寻求无限可能#

目标：在明确问题后，鼓励团队进行发散性思维，产生尽可能多、尽可能新颖的解决方案，不设限制，不作评判。
实践：头脑风暴（Brainstorming）、思维导图、SCAMPER 法则、类比思考。
意义：跳出固有思维模式，探索广阔的解决方案空间，找到突破性的创意。

4. 原型 (Prototype) —— 快速构建，将想法具象化#

目标：将构思阶段的想法，快速、低成本地转化为有形的产品模型，以验证核心假设。
实践：纸质原型、线框图、草图、可点击的交互原型、故事板。
意义：原型是沟通的工具，能让抽象的想法变得具体，便于用户理解和反馈。它避免了在不确定性下投入大量资源进行开发。

5. 测试 (Test) —— 验证假设，收集反馈#

目标：将原型呈现给真实用户，收集他们的反馈，验证解决方案是否有效，并从中学习。
实践：用户测试、A/B 测试、可用性测试、用户访谈。
意义：测试是设计思维的闭环。通过用户的真实反馈，我们可以学习到原型中的不足，从而回到「共情」或「定义」阶段，进行迭代改进。

设计思维的心智模式#

设计思维不仅仅是步骤，它更是一种深层的心智模式：

同理心：始终从用户角度出发。
乐观：相信每个问题都有解决方案。
迭代：接受不完美，从小处着手，持续改进。
实验：勇于尝试，从失败中学习。
协作：鼓励跨学科合作，价值多元观点。

结语#

在技术日益精进的今天，仅仅掌握「如何构建」已经不够。我们更需要培养「构建什么」以及「为谁构建」的智慧。

设计思维，正是这样一门「以人为本」的解决之道。它赋能我们跳出技术思维的局限，用同理心去理解世界，用创意去解决问题，用迭代去逼近卓越。

它让我们能够构建出真正被用户喜爱、并能创造商业价值的创新产品，这才是软件工程师的终极追求。

4.双菱形实践法则

Mon, 01 Jan 0001 00:00:00 +0000

设计思维的核心理念是「以人为本，迭代创新」。但如何将这些抽象的原则，转化为可操作、可执行的实践？双菱形（Double Diamond）实践法则，正是由英国设计委员会（British Design Council）提出的，一套将设计思维具象化的清晰框架。

它优雅地阐明了创新过程中发散（探索多种可能性）与收敛（聚焦于最佳选择）思维的交替进行。这就像一张地图，指引我们在充满不确定性的创新旅程中，高效、低风险地抵达目的地。

这篇文章，雪狼将带你穿越双菱形的旅程，掌握这套强大的创新方法论。

双菱形：创新旅程的「探照灯」与「罗盘」#

双菱形模型由两个相互连接的菱形构成，每个菱形代表一个「发散收敛」的循环。

第一个菱形：问题空间 (Problem Space)
- 探索（Discover）：发散性思维，去「发现」问题和洞察。
- 定义（Define）：收敛性思维，去「定义」核心问题。
第二个菱形：解决方案空间 (Solution Space)
- 设计（Develop）：发散性思维，去「构思」解决方案。
- 验证（Deliver）：收敛性思维，去「验证」并交付最佳方案。

穿越菱形的旅程#

第一阶段：探索（Discover） —— 洞察需求（发散）#

目标：尽可能广泛地收集信息，从不同角度理解用户、市场和技术，发现潜在的问题和机会。
核心问题：用户是谁？他们的痛点、需求、行为习惯和动机是什么？市场现状如何？
方法：用户访谈、问卷调查、行为观察、竞品分析、数据分析、用户旅程地图（User Journey Map）。
思维模式：跳出固有框架，拥抱不确定性，不作评判，广泛收集。

第二阶段：定义（Define） —— 聚焦问题（收敛）#

目标：对「探索」阶段收集到的海量信息进行整理、分析和提炼，从用户的角度，清晰准确地定义需要解决的核心问题。
核心问题：最关键、最有价值的问题是什么？我们究竟要解决什么？
方法：亲和图（Affinity Diagramming）、用户画像（Persona）、「如何才能…」（How Might We…?）问句、问题声明（Problem Statement）。
思维模式：提炼洞察，聚焦核心，明确挑战。

第三阶段：设计（Develop） —— 构思方案（发散）#

目标：针对「定义」阶段明确的核心问题，发散性地生成尽可能多、尽可能多样化的解决方案。
核心问题：有哪些可能的解决方案？有没有完全不同的思路？
方法：头脑风暴（Brainstorming）、思维导图、草图、故事板（Storyboard）、原型构思。
思维模式：鼓励创新，跳出常规，数量优先于质量。

第四阶段：验证（Deliver） —— 交付与迭代（收敛）#

目标：将「设计」阶段产生的最有潜力的方案，快速构建成原型，并与真实用户进行测试，收集反馈，验证假设，并不断优化。
核心问题：这个方案能解决用户的问题吗？它是否易于使用？它是否符合商业目标？
方法：构建原型（从低保真到高保真）、用户测试、可用性测试、A/B 测试。
思维模式：将想法付诸实践，快速学习，持续改进。

双菱形实践法则对程序员与架构师的好处#

结构化探索：提供清晰的路线图，帮助团队在复杂问题中找到方向。
降低风险：通过早期验证问题和方案，避免在后期投入大量成本才发现方向错误。
激发创新：鼓励在「探索」和「设计」阶段大胆发散，从而找到突破性的解决方案。
促进协作：为跨职能团队（业务、设计、技术）提供共同的语言和工作流程。
用户中心：始终将用户的真实需求置于核心，确保技术方案真正解决问题。

结语#

双菱形实践法则，是设计思维的精髓所在。它不仅仅是一套方法论，更是一种思维框架，它教会我们如何在复杂且不确定的环境中，系统地进行创新。

通过有意识地运用发散与收敛思维，我们能够从模糊的需求中洞察到真问题，从天马行空的创意中提炼出可落地的方案，并最终构建出真正被用户喜爱、并能持续创造价值的产品。

5.电梯演讲的艺术

Mon, 01 Jan 0001 00:00:00 +0000

设想一个场景：你走进电梯，正巧与公司的 CEO、一位重要的投资人，或是一位平时难以遇到的关键业务方，不期而遇。你只有短短 30 秒，甚至更少，来传达你的一个绝妙创意、一个产品的核心价值，或者你正在解决的一个关键问题。你能做到吗？

这，就是「电梯演讲（Elevator Pitch）」的艺术。它不仅仅是一项沟通技巧，更是程序员、架构师、设计师在快节奏、信息爆炸的时代，将复杂思想化繁为简、精准沟通的「核心内功」。

什么是电梯演讲？#

定义：电梯演讲是对一个想法、产品、项目或解决方案的简洁、引人入胜的总结，其长度旨在能在乘坐电梯的短暂时间（通常 30-60 秒）内完成。
目标：在短时间内抓住听众的注意力，激发他们的兴趣，从而为后续更深入的对话打开大门，而非立即达成交易。
比喻：它就像电影预告片。预告片不会讲述电影的全部故事，但它会以最精彩、最吸引人的片段来「钩住」你，让你产生想看完整电影的欲望。

为何对开发者和架构师是门「艺术」？#

对于技术背景的人士，电梯演讲尤为重要：

思想的清晰度：它强制你将复杂的、技术性的想法提炼成其最本质的、非技术性的语言。如果你无法用简单的语言解释清楚，那说明你还没有真正理解它。
沟通的有效性：在充满信息噪音的世界里，快速有效地传达你的核心信息是稀缺能力。
促进共识：它帮助团队内部统一对产品核心价值、项目目标的理解，确保大家劲往一处使。
影响力：它是从高层管理者、产品经理、业务伙伴那里获得认同、支持和资源的强大工具。

完美演讲的解剖：5W 法则#

一个成功的电梯演讲，通常包含以下「5W」要素：

Who? (谁？) —— 你的目标听众是谁？你的产品或想法是为谁服务的？
- 「对于那些[目标客户]，……」
What Problem? (什么问题？) —— 你正在解决什么痛点？你的目标听众面临的挑战是什么？
- 「……他们正在为[痛点]而苦恼，……」
What Solution? (什么方案？) —— 你的产品、想法或解决方案是什么？
- 「……我们的[产品/想法]是一个[产品类别]……」
Why Unique? (为何独特？) —— 你的产品或想法有什么独特之处？为什么它比其他方案更好？
- 「……它提供[关键优势]，而不同于[竞争对手]。」
Why Now? (为何此刻？) —— 现在是推出这个产品或实施这个想法的最佳时机吗？市场机会是什么？
- 「……在[当前市场趋势]的背景下，它将[带来什么影响]。」

示例（产品）：

「对于那些总在寻找新颖娱乐方式的年轻上班族，他们正在为日常生活的乏味和社交圈的狭窄而苦恼，我们的[沉浸式剧本杀小程序]是一个[结合线上社交和线下体验的娱乐平台]，它提供独一无二的沉浸式剧情和真人互动体验，而不同于传统的线上游戏。」

示例（架构师推销「微服务」概念）：

「对于那些业务快速发展、现有系统迭代缓慢的企业，他们正在为庞大单体应用带来的开发瓶颈和部署风险而苦恼，我们提议采用微服务架构，这是一个将系统按业务领域拆分为多个独立服务的方案，它提供团队自治、独立部署和技术栈灵活选择的能力，从而极大提升业务响应速度和系统稳定性。」

打磨演讲：熟能生巧的实践#

精简提炼：把所有不必要的细节都砍掉，只保留核心信息。就像毕加索的《公牛》，最终只剩下最本质的线条。
突出价值：你的想法能给听众带来什么好处？是解决问题？带来收益？还是降低风险？
富有激情：你的自信和热情是会感染人的。
反复练习：大声说出来，计时，并请朋友或同事提供反馈。

结语#

电梯演讲，不仅仅是销售的技巧，更是程序员、架构师、设计师将复杂思想化繁为简的「核心内功」。它训练你的思考深度、表达清晰度、以及在关键时刻抓住人心的能力。

在日益复杂和喧嚣的世界里，掌握这门艺术，你就能确保你的每一个闪光点，都能被及时捕捉，你的每一个创意，都能获得应有的关注和支持。

6.架构杂谈：737 MAX8 启示录

Mon, 01 Jan 0001 00:00:00 +0000

什么是架构？#

各位同学，我是雪狼。今天咱们不聊代码，聊聊飞机，特别是那架曾经让全球航空业为之震颤的波音737 MAX。你可能会问，这跟我们搞软件的有啥关系？关系大了去了！这背后，藏着工程、商业、物理定律多方妥协的无奈，以及技术决策中那些深刻的哲学思考。而这，不正是我们架构师每天都在面对的「取舍之道」吗？

别急着下结论，我雪狼今天就用这个血淋淋的案例，掰开揉碎了，给你讲讲什么叫「架构」，什么又叫「权衡」。在脑子里先记下两个关键词：整体和抽象。

首先，老规矩，咱们来看看百科里对「软件架构」的定义：

架构值多少钱？ —— 当「螺蛳壳里做道场」遇上「新挑战」#

当「老骥伏枥」遇上「新引擎」：一场技术与商业的「拧巴」#

各位同学，我是雪狼。你可能会觉得，「架构」这东西，听起来高大上，但到底值多少钱？我想说，它可能值几百条人命，也可能值几千亿美金。这绝不是危言耸听，咱们就拿波音737 MAX 这个「老伙计」的故事来掰扯掰扯。

想象一下，你有一辆开了几十年的老伙计，底盘扎实，操控顺手，你对它的一切都了如指掌，就像我们对一些经典代码库的感情一样。现在，时代变了，你想给它换个更强劲、更省油的发动机，以便在新的「市场竞争」中保持优势。问题来了，这新发动机又大又重，塞不进原来的「引擎舱」。咋办？你只能像「螺蛳壳里做道场」一样，把它往前挪，往上抬，勉强装进去。

这，就是波音737 MAX 当年面临的真实困境。737系列是航空史上最成功的窄体客机之一，但它的基本设计可以追溯到上世纪60年代。为了与竞争对手空客 A320neo 抗衡，波音决定在737的「老底盘」上，搭载更大、更省油的 CFM LEAP-1B 发动机。然而，737的机身离地较低，为了给这些直径更大的发动机提供足够的离地间隙，工程师们不得不将发动机安装位置向前、向上移动。这一改动，看似解决了空间问题，却悄然埋下了架构层面的深层隐患。我们常说「牵一发而动全身」，在架构设计中，这种「动」可不是闹着玩的。

意料之外的「抬头」与「补丁」：当「小聪明」成了「大祸患」#

发动机位置的改变，带来了意想不到的空气动力学效应。在某些飞行姿态下，特别是大迎角（Angle of Attack, AoA）飞行时，发动机短舱本身会产生额外的升力。由于发动机位于飞机重心前方，这股升力会产生一个向上的力矩，导致飞机机头自动上扬，也就是所谓的「抬头趋势」。这种「抬头趋势」在工程上被称为「不稳定或发散条件」，对于客机而言是不可接受的。

按照规定，飞机在接近失速时，操纵杆的反馈力应该逐渐增大，以提醒飞行员。但737 MAX 的这种新特性，却让飞行员在拉杆时感觉更「轻」，这与737系列一贯的操纵特性不符。各位同学，你们在开发中，是否也遇到过这种「老代码新需求」带来的「别扭」？

为了让737 MAX 的操纵感受与之前的737型号保持一致，从而避免飞行员进行昂贵的模拟机训练（这是航空公司和波音都希望避免的成本），波音引入了一个新的软件系统 —— 机动特性增强系统（Maneuvering Characteristics Augmentation System），简称 MCAS。MCAS 的「初心」是好的，它旨在通过自动下压机头，来抵消这种不自然的抬头趋势，让飞机在飞行员手中依然是那架熟悉的737。

「一叶障目」的悲剧：架构缺陷的「连锁反应」#

然而，正是这个旨在弥补物理架构缺陷的「软件补丁」，最终酿成了两起震惊世界的空难。MCAS 的设计存在一个致命缺陷：它仅仅依赖于一个迎角传感器的数据来判断飞机是否处于大迎角状态。这意味着，如果这个唯一的迎角传感器发生故障，提供了错误的数据（例如，错误地指示飞机处于大迎角），MCAS 就会被错误地激活，反复地将机头向下压。飞行员虽然可以尝试通过手动操作来对抗，但 MCAS 的设计允许它在短时间内多次激活，并且其下压的力度可能非常大，使得飞行员难以有效干预。

在2018年的狮子航空610号航班和2019年的埃塞俄比亚航空302号航班空难中，正是由于错误的迎角传感器数据，导致 MCAS 系统反复启动，将飞机推向了无法挽回的俯冲，最终造成了346人遇难的悲剧。

所以，架构值多少钱？显然，对这次 MAX8 事件波音会赔很多钱，至于间接损失多少钱，还是个未知数。这不单单是金钱上的损失，更是对品牌、声誉，乃至整个行业信任的巨大冲击。

架构为什么重要？最简单的答案是：因为它真的很值钱，值到你可能想象不到的代价。 那些看起来无关紧要的底层设计决策，最终会通过一系列的「补丁」和「妥协」，在某个临界点爆发，成为无法承受之重。这就像我们写代码一样，一个小小的初期设计缺陷，可能会导致后期无数的加班和 bug，甚至重构。

架构是一种权衡 —— 「中庸之道」的工程实践#

各位同学，我雪狼常说，设计是一种权衡。这话没错，但对于架构设计而言，它更是一场关于「取舍」的艺术，一场在多重矛盾目标中寻找「中庸之道」的艰难实践。比如737的架构中较低的机翼，这在当年可是个「设计亮点」：它大大降低了检修成本，提升了运营效率。而其代价呢？就是难以加挂更大、更先进的发动机。

显然，在当时的需求和技术条件下，低检修成本带来的竞争优势是巨大的，而更大、更省油的发动机那会儿还没影儿，更别提有多紧迫的需求了。这种「幸福」的局面持续了四十多年，直到竞争对手空客 A320 neo 带着更先进、更省油，也更大直径的发动机横空出世。

这时候，波音面临的权衡就变得异常残酷了。省油，变成了市场最迫切的需求，而更大的发动机，也就成了由业务需求衍生出的硬核技术需求。这个「新需求」，与 737 老旧架构的固有约束产生了剧烈冲突。

虽然我们可以通过「打补丁」的方式，貌似很「聪明」地解决了这种冲突（比如用软件 MCAS 来「纠正」物理问题），但这种所谓的「小聪明」，往往会在架构级别埋下巨大的隐患。这种架构级的冲突点，就像被不断拉扯的橡皮筋，其内部的「应力」会越来越高，最终可能在某一个临界点，彻底撕裂。

各位同学，在做架构时，务必深入理解它当初做出的那些「牺牲」和「选择」。不了解这些权衡，你就没真正理解这个架构。 千万不要轻易使用「小聪明」去解决架构级冲突，那无异于「头痛医头脚痛医脚」。真正的解法，要么是调整架构，要么是选择与现有架构没有本质性冲突的部件。 这就是我们常说的「知其然，更要知其所以然」，否则，你解决的可能只是表象，而真正的「病灶」却在深处 fester。