架构设计是系统成功的基石，其核心价值在于通过一系列严谨的思考和权衡，为系统构建一个可靠、可扩展且可持续演进的蓝图。它不仅决定了系统的技术实现，更深远地影响着团队的协作效率、项目的交付成本与未来的维护难度。
那么在架构设计过程中，有5个贯穿架构过程的关键点内容：
1.首先，通过架构决策记录（ADR） 规范化决策过程，确保每一个重要选择的背景、权衡与依据都被清晰记录，这不仅保障了设计的一致性，也为团队积累了宝贵的知识资产。
2.其次，强调聚焦关键设计，针对不同项目类型（如新建应用、数据系统或迁移项目）采取差异化策略，确保设计力度用在刀刃上。
3.同时，我们高度重视技术评审的作用，它不仅是汇集集体智慧的技术活动，更是达成共识、明确责任、分散项目风险的关键协作机制。
4.此外，所有设计都必须经过压力测试的验证，将性能评估从理论转化为实践，提前暴露系统瓶颈，这是保障系统上线后稳定性的不可或缺的环节。
5.最后，明确系统边界是设计的第一步，它直接定义了系统的内外部职责与协作契约，是减少团队间摩擦、控制项目范围和控制成本的核心手段。
一、架构决策记录 (Architecture Decision Record, ADR)
架构决策记录是一种轻量级的文档，用于记录一个重要的架构决策、其上下文和后果。可以把它理解为架构层面的“实验记录”或“会议纪要”。它的核心价值不在于记录“我们做了什么”，而在于回答“我们为什么这么做”、“我们考虑了哪些方案”以及“为什么否决了其他方案”。这是极其重要的~~也是个人经验的沉淀。记录的是决策的“演变过程”，像一个动态的日志。它捕获了决策时的思考过程，使得未来的团队成员和自己都能够理解过去的权衡。
下面是ADR的8大核心要素
下面是ADR的一个简单例子：
内容不一定需要太多太复杂，但是要把关键的决策背景和原因写清楚。
二、4A架构是企业级的
“4A”是国内架构领域对TOGAF核心内容架构（Content Framework）中四个核心架构域的一种概括和俗称。这“4A”指的是：
|
架构域 |
核心关注点 |
要回答的问题举例 |
|
业务架构 (Business Architecture) |
定义企业的业务战略、治理、组织和关键业务流程。 |
我们的业务目标是什么？核心业务流程是怎样的？组织架构如何？需要什么角色和能力？ |
|
数据架构 (Data Architecture) |
描述组织的逻辑和物理数据资产以及数据管理资源的结构。 |
企业的核心数据实体是什么？（如客户、产品）数据如何被存储、管理、集成和共享？ |
|
应用架构 (Application Architecture) |
为要部署的单个应用系统、它们的交互关系以及它们与核心业务流程的关系提供蓝图。 |
我们需要哪些应用系统？（如CRM, ERP）这些应用之间如何交互？它们如何支持业务流程？ |
|
技术架构 (Technology Architecture) |
描述支持业务、数据和应用服务部署所需的逻辑软件和硬件能力。 |
我们需要什么样的硬件、服务器、操作系统、网络和中间件？我们的技术标准和选择是什么？ |
这四者共同构成了企业架构的完整视图，是TOGAF架构开发方法（ADM）的核心产出物。在TOGAF中，这四个架构域并不是孤立存在的，它们通过架构视图和视点相互关联，共同描述了企业从“为什么做”（业务）到“做什么”（数据和应用）再到“怎么做”（技术）的完整蓝图。
这里面一定要注意的一点，4A架构是企业级的架构，这比一个项目的架构大很多。4A架构（企业级）定义“规则和赛场”，项目软件架构（系统级）定义“球队如何在这个赛场上打球并赢得比赛”。 项目软件架构必须在4A架构设定的边界和规则内进行设计和创新。
一个肤浅的对比：
|
对比维度 |
4A架构 (企业架构 – EA) |
项目软件架构 (解决方案/系统架构 – SA) |
|
范围 (Scope) |
企业级/领域级。横跨多个项目、系统和业务单元。关注整个组织的一致性。 |
项目级/系统级。聚焦于单个特定的系统、应用程序或服务。 |
|
目的 (Purpose) |
战略对齐和整体优化。确保技术投资与业务战略一致，降低复杂度，促进集成，管理企业级技术风险和技术债务。 |
项目成功交付。确保所构建的特定系统满足功能性/非功能性需求（如性能、安全、可维护性），并在给定的约束（时间、预算）内实现。 |
|
主要受众 (Audience) |
企业架构师、高层管理者、业务负责人、项目经理（从战略层面）。 |
系统架构师、开发团队、项目经理、测试负责人。 |
|
抽象层次 (Abstraction) |
高阶、宏观、逻辑。定义 “是什么” (What) 和 “为什么” (Why)。 |
中低阶、具体、物理。定义 “怎么做” (How)。 |
|
（例：“我们需要一个统一的客户数据平台”） |
（例：“客户数据平台将采用微服务架构，使用Spring Cloud框架，由A、B、C三个服务构成，数据库选用MySQL，通过Kafka同步数据……”） |
|
|
时间视角 (Time Perspective) |
长期（3-5年甚至更久）。相对稳定，变化缓慢。 |
短期（一个项目周期）。随着项目需求和技术的演进可能变化较快。 |
|
关键产出 (Outputs) |
架构原则、技术标准、平台选择、系统交互图、数据流图、未来状态蓝图。 |
系统架构图、技术栈选型、模块划分、API规范、部署模型、数据库设计。 |
|
驱动因素 (Drivers) |
由业务战略驱动（例如：数字化转型、进入新市场、合规性要求）。 |
由项目需求驱动（例如：开发一个新功能、重构一个老系统、集成一个第三方服务）。 |
上面写的太多抽象了，4A架构中的每一个架构不是一个简单的图就能表达的，例如业务架构要深入每个业务部门的关键活动。后面在单独写写看了。
另外呢，在toagf10中，已经提出6A架构了，不再是4A架构了。
|
架构维度 |
TOGAF 9.2 (4A架构) |
TOGAF 10 (6A架构) |
主要变化与提升 |
|
业务架构 |
描述业务战略、组织、流程  |
描述业务战略、组织、流程 |
地位保持不变，仍是核心驱动力。 |
|
应用架构 |
描述应用系统布局与交互 |
描述应用系统布局与交互 |
地位保持不变，关注应用功能和服务。 |
|
数据架构 |
管理数据资产、模型和流 |
管理数据资产、模型和流 |
地位保持不变，确保数据一致性和有效性。 |
|
技术架构 |
定义硬件、软件等技术支持 |
定义硬件、软件等技术支持 |
地位保持不变，提供基础技术支撑。 |
|
系统集成架构 |
❌ 无独立架构（内容分散在其他架构中） |
✅ 新增独立架构 |
系统交互更清晰：专注于系统、服务、数据的集成方式与接口管理，确保系统协同工作。 |
|
安全架构 |
❌ 无独立架构（安全考虑分散在各架构中） |
✅ 新增独立架构 |
安全全面融入：作为横跨性领域，涵盖安全策略、身份认证、数据加密、安全审计等，贯穿所有其他架构域。 |
三、评审的重要性
这里想补充一点关于【评审】的重要性。评审这个活动，表面上看起来可能有些繁琐，尤其对于像我这样曾经不喜欢沟通、又比较自信的人来说，过去总倾向于自己决定、直接执行——当然，如果判断准确，推进速度会快，这本身没问题。
但评审更深层的意义，不仅仅在于汇聚大家的智慧、群策群力，它还有一个非常现实的作用，就是让更多关键人员提前参与进来、形成共识和责任共担。换句话说，这也是某种程度的“风险分散”：一旦将来项目出现问题，或在推进过程中出现未预料到的困难，就不会有人突然跳出来无端指责、推卸责任——因为他们都参与了评审，当时没有提出异议，事后自然也就没有立场指手画脚。
我特别提到这一点，倒不是说我们要刻意“耍心眼”，而是在理想情况下，我们既要追求集思广益，也要理解协作机制中的现实层面。评审既是一种技术保障，也是一种沟通与承诺的仪式。
另外呢，不同的人对架构的关注视角是不一样的，有些关注安全性，有些关注稳定性，有些关注时效性，要想项目顺利结项，让这些关键的人签字，就得尽量实现他们的目标，最终得到他们的认同。不然到了最后，给你扯东扯西，那项目就没完没了了。
最后就是“小鬼难缠”，一定要在这种领导们都在会上，把很多说清楚，不然这些“小鬼”老是耍小聪明，令项目做的举步维艰。把很多问题都在会上提出来，形成结论和会议纪要，下来没谁会再跳出来乱搞了。
四、系统的边界（周边关系）
明确系统的边界（或称周边关系）是架构设计中又一个至关重要的一步。明确系统边界的主要目的是划定职责范围，定义交互契约。它回答了以下两个基本问题：
1.“什么是系统负责的？” (对内职责)
2.“系统需要谁帮助，又为谁服务？” (对外交互)
个人有时比较狭隘，觉得最核心的还是任务分工，明确团队间的职责划分明确，减少推诿和冲突。如果是乙方团队，这也是项目范围，多扩大一点边界就是要多花成本，甲方又不买单。。。
所以嘛，有个至理名言（康威定律）：组织架构决定系统架构。组织只要定下来了，系统的边界也就定了。系统边界定了，系统的架构也基本定了 。因为一个组织的边界，就决定了“我只做什么，哪些我不做。然后大家开始吵架。”
比如，一个小小的故事:
场景： 甲方提出一个“简单”的需求：“在管理后台的商品列表页，不仅要显示我们平台数据库里的实时库存，还要显示从WMS同步过来的在途库存和物理库存。”
这个需求触发了三个团队间的“战争”：
Team B（后端业务团队）的理解：
“管理后台是我们’核心业务平台’的一部分，这个需求需要我们提供一个新API。”
“但是库存数据不在我们这里，在Team C的’数据集成服务’里。我们得找他们要数据。”
他们的动作：向Team C提需求：“请提供一个查询商品多维库存的API。”
Team C（集成团队）的理解：
“我们的职责是’数据同步’，就是把ERP/WMS的数据定时同步到业务平台的数据库里。我们已经把数据同步给你们了。”
“现在你要的是一个新的、实时查询的API，这超出了我们’同步数据’的职责范围（Scope Creep）。这是个新需求，要评估工作量，可能要加钱。”
“而且，直接让前端去调用WMS的API？不行，安全、协议、稳定性都是问题，必须经过我们的集成服务。”
他们的动作：回复Team B：“这是新需求，需要走需求变更流程，评估人天。”
Team A（前端团队）的处境：
“我们就在等一个API。页面早就做好了，就差接口了。”
“为什么这么慢？不就是个查询吗？”
他们的动作：催Team B：“客户在催了，什么时候能好？”
Team B（夹在中间）的委屈：
“Team C不配合，我们也没办法。这不是我们团队能控制的。”
他们的动作：对项目经理说：“要么让甲方加钱，要么让甲方砍需求，要么就让Team C赶紧做。”
于是，大家开始吵架了。 项目会议变成了甩锅大会：
Team B: “是集成团队进度延迟了。”
Team C: “是业务团队一开始没想清楚需求，而且这是范围外的。”
Team A: “我不管你们后台谁做，我只要API！”
最终结果：一个简单的需求，因为横跨三个团队的边界，导致了巨大的沟通成本、推诿和延迟。这就是组织边界决定了系统边界，进而导致协作冲突的完美体现。
那如何解决这问题？一个粗鲁的办法，直接合并成一个团队。。。那么就没有壁垒了。一个团队内不会吵那么大了。另外就是找一个“裁判”（架构组）来裁决。
明确的“系统边界”，带来如下的好处：
1.控制范围蔓延： 这是作为乙方最深有体会的一点。清晰的边界就是项目的“防护墙”。任何试图跨越边界的需求都可以被清晰地识别为“范围变更”，从而触发额外的成本、资源和时间评估。这是对乙方团队最重要的保护。
2.精确的工期与成本估算： 边界模糊会导致职责不清，最终就是工作量无法估算。而边界清晰后，每个团队对自己负责的模块工作量有更准确的判断，项目经理也能因此汇总出更可靠的整体计划。
3.并行开发，提升效率： 一旦接口（API/协议）定义清楚，不同的团队就可以基于接口契约并行开发自己的模块。前端可以mock后端接口，服务A团队可以独立于服务B团队进行开发。这极大地缩短了开发周期。
4.降低风险： 依赖关系明确了，项目中的关键路径和风险点也就一目了然。项目经理可以提前关注那些被多个模块依赖的核心服务，避免其成为项目瓶颈。
五、如何量化一个架构的好坏
这个比较复杂，以后再说吧。
六、 后记
今天睡了一天，这软件行业，现在搞得跟服务业一样。。太累了。。
七、 参考资料：