本专栏用于部分书中优质内容的摘抄，请注意，只是那部分相对来说对于我个人感触较大的，不是对于全部内容，叠个盾()

问题空间和解决方案空间

对于一个软件开发，从本质上来说，其就是问题空间（Problem Space）到解决方案空间（Solution Space）的一个映射转化，如下图。

在问题空间中，对应的关注点是当前业务正面临着的问题，通过识别问题，挖掘并分析相关的场景用例，最终勾线出对应的抽象模型，将业务领域关键事务以及关系进行可视化呈现。而在解决方案空间中，关注点则是通过具体的软件技术手段来进行系统设计以及实现。

更抽象来说，所谓的问题空间所回答的是一个做什么，即，存在哪些需要解决的问题，对应的问题的背景是什么，需求是什么等等，这需要结合的是现实中的甲方的需求进行详细的分析的。对于解决方案空间，其回答的是一个怎么做的问题，即，我需要选择什么样的工具去实现当前这个业务，为什么，怎么用一个中间件等等。通过这俩个空间的结合，从做什么以及怎么做这来个理论以及实践的方面来回答一个开发实际所需要做的简略流程。

架构

架构一词难以官方定义，引用书中引用的一个定义以及对应的图。ISO/IEC 42010:20072 中对架构的定义为：“架构是一个系统的核心组织，用于阐明模块或组件的职责，以及相应的约束设计和演化原则。”根据定义，可以概括出如图 4-1 所示的公式。

但是对于我来说，我存在一个考虑，就是为什么要给一个词下一个定义？对其下一个定义对于我们来说存在什么作用？使用外人给出的定义相对来说对于我们来说存在什么作用？

基本对于现在的我(2025-8-26)来说，我个人理解的，对于一个词下一个定义，首先会有一个先决条件，就是其足够复杂以及抽象，就比如架构一词，即使说平常时常使用，但是在切实的想抓住其并进行理解时却由于其过于抽象会难以理解，这是如果有别人的一个过往经验来辅助理解将是极好的。

回过头来，所谓的架构，个人感觉，实际上是对于一个开发流程中的规范，其所想描述的是到底系统中存在什么，为什么存在这些以及这些之间存在什么等等。这是由于一个软件开发流程中实际上都存在一个周期，即使是对于目前我这种没有参与过企业开发流程的来说，我对于个人项目的把握也会在一段时间淡忘很多，如果想要在淡忘后能够较为高效的重新拾起对应的内容，势必需要一层规范来约定在之前开发流程的操作。通过这一层对应的约束，其能够使得整体的开发流程稍微的可控。

依照书中所说，架构本身存在三大支柱:

模块/组件 (Building Blocks)：系统由哪些核心部分构成？这是结构的静态描述。
职责与关系 (Responsibilities & Interactions)：各个部分做什么（职责）？它们之间如何协作（关系）？这是行为的动态描述。
指导原则 (Guiding Principles)：设计和演化的规则与约束。为什么这样设计？未来变更要遵循什么原则？（例如：“所有模块间必须通过API通信，禁止直接读写数据库”、“系统必须支持水平扩展”）。这是最容易忽略但最能体现架构师价值的部分。

这三个是上面的公式对于一个软件的高度概括，实际上，通过这三个支柱，我们能够形成其自己去窥探一个新接触的项目的路径。就比如，看到一个系统，就问自己三个问题：它的核心组件是什么？它们怎么分工协作？它遵循了什么设计原则？

基础了解了什么是架构之后，我们从另外一个方面来了解架构本身是怎么在一个软件开发流程中存在的

架构类型	所属空间	核心关注点（回答什么问题）	产出物形态（像什么）	目的
业务架构	问题空间	“做什么？” 产品有哪些业务模块？每个模块提供什么能力？模块间如何业务联动？	业务蓝图（类似于企业组织架构图）	统一共识让产品、研发、业务方对要构建的业务世界有一致的认知。
逻辑架构	解决方案空间	“怎么做？” 系统有哪些软件模块？模块间接口如何定义？关键流程如何实现？	系统设计图（如UML组件图、时序图）	指导开发告诉开发人员系统的组成部分和协作方式，是编码的直接依据。
物理架构	解决方案空间	“怎么运行？” 软件部署在多少台机器上？如何配置网络和负载均衡？如何满足性能、可靠性等非功能需求？	部署架构图（标有服务器、网络、中间件的拓扑图）	指导部署运维告诉运维人员如何让系统高效、稳定、安全地跑起来。

总的来说，对于架构这个概念本身的解构，实际上不要求我们本身在一开始就能够去所谓的开始架构一个本身的大型应用，实际上其是相对潜移默化的，就比如对于我来说，我能够在了解了上诉架构本身的三个支柱以及对应的架构所处的时间片以及一些信息之后，我能够在后续的review中，更好的考虑到到底为什么做这个，到底怎么与其他模块联动等，而不是局限于当前的业务的上下文。

以及存在最重要的一点，我们最快的学习方法，实际上就是去找一些比自己牛的人去沟通，但是很多时候对于人来说都是厌蠢的，对于本人也是一样，或者说，无论对于任何人都一样，你不能期望你所提出的一个抽象的问题能够得到别人的回答，你在回答之前，你需要先明确我该问题到底需要问什么，对应的我个人的实际需求是什么，以及怎么减少废话。特别是在软件这一领域，对于如何架构本身的问题实际上也是一门学问。就比如说，我从谈论架构一次开始到现在，我已经偏离了我一开始的预想结构，甚至于我当前也不知道怎么回归，你怎么看呢？

以下为AI总结后的一个版本，选择观看

文本摘抄（精简版）

问题空间 & 解决方案空间

问题空间（Problem Space）：回答 做什么。
→ 识别业务问题、场景、用例，抽象出领域模型（业务要素+关系）。
解决方案空间（Solution Space）：回答 怎么做。
→ 通过技术手段进行系统设计、模块划分、实现与部署。
二者结合：从「需求 → 技术方案」的转化路径。

架构的定义与价值

ISO/IEC 42010:2007 定义：架构 = 系统的核心组织 + 模块职责 + 约束设计与演化原则。
个人理解：
- 定义的价值：为复杂、抽象的事物提供理解的“抓手”。
- 架构本质：对系统的组织方式进行规范，帮助长期维护和迭代，避免遗忘和失控。

架构三大支柱

模块/组件：系统由哪些核心部分构成？（静态结构）
职责与关系：各部分负责什么？如何协作？（动态行为）
指导原则：设计和演化的约束与规则（如“必须 API 通信”、“支持水平扩展”）。
👉 学习或观察系统时，可以反问：核心组件是什么？如何协作？遵循什么原则？

架构的类型

架构类型	所属空间	回答的问题	产出物	目的
业务架构	问题空间	做什么？	业务蓝图	统一共识
逻辑架构	方案空间	怎么做？	系统设计图	指导开发
物理架构	方案空间	怎么运行？	部署架构图	指导运维

学习架构的启示

不必急于“设计大而全的架构”，更重要的是在迭代和 Review 中逐步体会“为什么这样设计，如何联动”。
提问/学习要具体化：先明确需求，再减少废话。
架构思维 = 一种心智模型，帮助在复杂系统中抓住核心、协作、原则三个锚点。