1. 课程导论与架构思维：什么是软件架构？为什么需要架构设计？架构师的职责与思维模型。
大家好，我是你们这门课的老朋友。咱们今天聊聊一个看似很虚、实则很实的话题——软件架构。
说实话，我见过太多团队，一上来就写代码。需求文档还没捂热，就开始堆功能。结果呢？三个月后，代码乱成一锅粥。改一个bug，冒出三个新bug。项目经理天天催，开发人员天天加班。嗯，这种场景，你肯定不陌生。
为什么会这样？说白了，就是缺了架构设计这一步。
1.1 什么是软件架构？
先问个问题：你盖房子，会直接砌砖吗？肯定不会。你得先画图纸，定结构，算承重。软件架构，就是软件世界的“图纸”。
我个人习惯把架构定义为：软件系统的骨架与决策。它决定了系统有哪些模块，模块之间怎么通信，数据怎么流转，以及系统如何应对变化。
举个例子。我几年前参与过一个电商项目。一开始，团队把订单、支付、库存全写在一个大项目里。这就是典型的“单体架构”。后来业务量上来了，每次改支付逻辑，都得把整个系统重新部署一遍。风险极高。这就是架构没设计好的后果。
架构的核心三要素：
- 结构：系统由哪些组件构成？
- 行为：组件之间如何交互？
- 决策：为什么选择这种方案？
你想想看，架构不是代码，但它决定了代码能写成什么样。它是一系列有意识的、有约束的设计选择。
1.2 为什么需要架构设计？
很多新手觉得：“架构？那是大厂才需要的东西。我们小项目，直接干就完了。” 我以前也这么想。直到有一次，我接手一个“小项目”——一个内部工具，代码只有几千行。但因为没有架构，代码耦合严重。我想加一个导出Excel的功能，结果发现要改五个模块。改了两天，还引入了数据不一致的bug。
从那以后，我明白了：架构设计不是奢侈品，而是必需品。它解决的是系统的“非功能性需求”。
| 维度 | 没有架构设计 | 有架构设计 |
|---|---|---|
| 可维护性 | 改一处，崩一片 | 模块化，改局部不影响全局 |
| 可扩展性 | 加功能像堆乐高，随时倒塌 | 预留扩展点，新功能即插即用 |
| 性能 | 上线后才发现扛不住 | 设计阶段就考虑瓶颈 |
| 团队协作 | 代码冲突天天有 | 职责清晰，并行开发 |
说白了，架构设计就是用前期的思考，换取后期的稳定。你前期多花一周做设计，后期可能省下一个月去填坑。
1.3 架构师的职责与思维模型
好，那架构师到底干什么？不是画几张UML图就完事了。我总结下来，架构师的核心职责有三点：
- 技术决策：选型、定规范、做权衡。比如用微服务还是单体？用MySQL还是PostgreSQL？
- 风险识别：提前发现潜在的技术债务和性能瓶颈。我曾经在一个项目中，发现团队选的ORM框架在批量插入时性能极差，及时换了方案，避免了上线后的灾难。
- 沟通协调：把技术方案讲给产品听，把业务需求翻译给开发听。架构师是桥梁，不是孤岛。
避坑指南： 我曾经犯过一个错——过度设计。项目还没上线，我就引入了分布式事务、消息队列、缓存集群。结果呢？系统复杂度飙升，开发周期拉长，最后业务根本没那么多流量。记住：架构是演进出来的，不是设计出来的。先做简单方案，再根据实际压力迭代。
说到思维模型，我特别推崇“第一性原理”。什么意思？就是遇到问题，别急着套现成方案。先问自己：这个问题的本质是什么？我们到底要解决什么？
举个例子。产品说：“我们要加一个实时排行榜。” 你第一反应可能是：“用Redis的Sorted Set！” 但如果你用第一性原理思考：本质是“需要快速获取Top N数据”。那方案就多了——内存排序、数据库索引、甚至预计算。Redis只是其中一种实现。这样思考，你才不会陷入技术偏见。
另一个重要的思维是“关注点分离”。把不同维度的关注点拆开。比如业务逻辑和基础设施分离，读操作和写操作分离。这样，每个部分都能独立演进。
注意： 架构师不是“代码警察”。不要事无巨细地规定每一行代码怎么写。你的任务是定好边界、接口和约束，给团队留出实现自由。否则，你会成为团队的瓶颈，大家都会等你拍板。
最后，我想说：架构思维不是天生的，是练出来的。你每做一个项目，都试着问自己：如果让我重新设计，我会怎么改？慢慢地，你就能从“写代码的人”变成“设计系统的人”。
好，这一章就到这里。下一章，咱们聊聊需求分析——怎么从一堆模糊的业务描述中，提炼出真正的架构需求。这是架构设计的起点，也是很多团队翻车的地方。