项目与协作CASE 01
项目管理系统为什么要先划清项目、任务和成员边界？
用户正在做什么
团队持续增加合同、任务、工时、风险和权限功能。
业务会出什么问题
模块边界不清会让任何改动都触碰大量代码和数据，团队也无法明确负责范围。
技术怎样介入
Architecture 定义 Module、依赖方向和 Data Ownership，让每个业务能力有清晰责任。
产品与设计怎样落地
设计信息架构时同步识别业务对象、状态和跨模块操作。
M3 · Chapter 08
软件架构
理解系统如何划分边界、组织依赖并持续演进。
先看哪些场景
项目与协作、多租户 SaaS、订单与支付、性能与扩容、内容与媒体
它是什么
软件架构规定系统的主要模块、边界、依赖、通信方式和运行结构。
为什么需要
业务和团队扩大后，代码如何拆、服务如何协作、数据如何管理会直接影响交付速度和稳定性。
位于哪一层
横跨应用、数据和基础设施层，是系统级组织方式。
和谁连接
单体、模块化单体、微服务、API Gateway、负载均衡、服务发现、Serverless 和领域边界。
项目里怎么出现
企业通用能力库、订单系统、支付系统和多团队平台都会面临架构选择。
Learning Outcomes
学完这一章，你应该能
- 理解架构关注边界与依赖
- 区分单体、模块化单体和微服务
- 理解 Gateway、负载均衡与服务发现
- 能判断微服务是否与当前规模匹配
08.01
架构到底在设计什么？
架构通过边界和依赖，让复杂系统保持可理解、可修改和可运行。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
架构会回答：业务模块怎么划分，谁可以调用谁，数据由谁拥有，模块如何部署，失败如何隔离，系统如何扩容。
技术框架和云产品会变化，稳定的业务边界、职责和契约更重要。架构也会受到团队结构、发布流程和合规要求影响。
Business Domains → Modules / Services → Contracts → Data Ownership → Deployment
System View
产品与业务目标
领域与模块边界
接口与依赖规则
数据归属
部署与运行结构
质量属性
Designer Lens
设计系统通过组件边界管理界面复杂度，软件架构通过模块边界管理业务复杂度。
ArchitectureModuleData Ownership
08.02
Monolith：单体架构
多个业务模块作为一个应用构建和部署。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
多租户 SaaSCASE 01
五人创业团队为什么常从单体开始？
用户正在做什么
团队要快速上线客户、项目、账单和通知功能。
业务会出什么问题
过早拆很多服务会增加部署、通信和运维成本，反而拖慢验证。
技术怎样介入
Monolith 把模块放在一个 Deployment Unit 中，共享进程和常见基础设施。
产品与设计怎样落地
产品迭代快时先保持业务边界清晰，暂时不追求独立部署。
单体应用可以包含用户、项目、订单和支付模块，通常共享一个代码仓库和部署单元。它开发、调试和事务处理更直接。
单体不等于混乱。清晰模块、依赖约束和测试可以让单体长期健康。小团队和早期产品常从单体获得更高效率。
One Application → Multiple Modules → One Deployment Unit
System View
app/
├─ users/
├─ projects/
├─ billing/
├─ files/
└─ notifications/
一次构建，一次部署Designer Lens
产品早期先跑通业务流程，架构保持清晰边界即可，不必为想象中的规模提前拆散。
MonolithDeployment UnitCoupling
08.03
Modular Monolith：模块化单体
保持单体部署，同时建立严格内部边界。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
项目与协作CASE 01
单体项目越来越大，怎样先避免代码互相侵入？
用户正在做什么
项目、合同和财务功能仍由一个团队部署，但各模块频繁互相读取内部数据。
业务会出什么问题
高 Coupling 会让局部改动引发连锁影响。
技术怎样介入
Modular Monolith 用 Encapsulation、Contract 和 Dependency Rule 限制跨模块访问。
产品与设计怎样落地
导航和业务流程可以跨模块，数据修改仍通过明确接口完成。
每个业务模块拥有自己的逻辑、接口和数据访问，其他模块通过公开能力调用，避免直接操作内部实现。
它保留单体的部署和事务优势，同时为未来拆分服务准备边界。很多业务系统在这个阶段已经足够。
One Deployment；Clear Internal Modules and Contracts
System View
普通混合单体
- 跨目录直接调用
- 共享内部数据
- 修改影响难预测
模块化单体
- 清晰公开接口
- 模块内部封装
- 依赖方向受约束
Designer Lens
“组件化”与“服务化”都要先明确职责、输入、输出和维护责任。
EncapsulationContractDependency Rule
08.04
Microservices：微服务
业务能力被拆成可独立开发、部署和扩容的服务。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
订单与支付CASE 01
大型电商为什么把订单、支付和库存拆成微服务？
用户正在做什么
不同团队分别负责订单、支付和库存，促销时各模块流量增长也不同。
业务会出什么问题
一个应用统一发布会让团队互相等待，订单高峰也迫使所有模块一起扩容。
技术怎样介入
按 Service Boundary 拆成 Microservice，每个服务可 Independent Deployment 和独立扩容。
产品与设计怎样落地
产品流程要接受跨服务延迟、处理中状态和部分失败，避免假设所有步骤瞬间完成。
用户服务、订单服务、支付服务可以由不同团队维护，并拥有独立发布节奏和资源。服务通过 API、RPC 或消息通信。
独立性带来更多网络调用、数据一致性、部署、监控和故障处理成本。服务边界应围绕稳定业务能力和团队责任划分。
Client → Services；Service ↔ Service；Each Service → Own Data
System View
API Gateway
→
Document Service
→
Excel Service
→
Notification Service
→
各自数据与运行环境
Designer Lens
会议里的“文档管理服务”和“Excel 服务”属于把通用能力做成独立可调用服务的思路。
常见混淆 · 微服务是否代表每个小函数独立部署？
服务边界通常对应完整业务能力，过细拆分会造成大量通信和维护成本。
MicroserviceService BoundaryIndependent Deployment
08.05
Gateway、Load Balancer 与 Service Discovery
它们分别解决统一入口、实例分流和动态寻址。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
性能与扩容CASE 01
大促期间一百万请求如何进入几十个服务实例？
用户正在做什么
Web、App 和小程序同时请求订单、商品和用户服务。
业务会出什么问题
客户端直接记住每个实例地址会失控，单台服务器也无法承受全部流量。
技术怎样介入
API Gateway 提供统一入口，Load Balancer 分配请求，Service Discovery 让服务找到可用实例。
产品与设计怎样落地
统一入口可提供一致的登录失效、限流、维护和版本提示。
API Gateway 位于客户端和服务之间，承担路由、鉴权、限流和协议转换。Load Balancer 把请求分发给同一服务的多个实例。
Service Discovery 让服务在动态环境里找到其他服务的位置。Kubernetes 等平台会提供部分服务发现和负载均衡能力。
Client → Gateway → Load Balancer → Service Instances；Service Registry → Address
System View
客户端
→
API Gateway
→
负载均衡
→
实例 A / B / C
→
数据库与外部能力
Designer Lens
同一产品界面通常看不到这些组件，但它们影响登录、错误、延迟和可用性。
API GatewayLoad BalancerService Discovery
08.06
Serverless 与事件驱动
部分能力可以按请求或事件临时运行，由云平台管理服务器。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
内容与媒体CASE 01
用户上传图片后，为什么可以自动生成缩略图？
用户正在做什么
图片进入对象存储后，需要生成多种尺寸并提取元数据。
业务会出什么问题
长期保持一台专用服务器空闲会浪费资源，流量也高度波动。
技术怎样介入
存储事件触发 Function as a Service，Serverless 平台按调用运行；首次启动可能出现 Cold Start。
产品与设计怎样落地
生成期间显示处理中，首个请求可能稍慢，失败时允许重新处理。
Serverless Function 在请求、文件上传或定时事件发生时执行，按使用量计费。团队无需直接管理长期运行的服务器。
它适合边缘接口、Webhook、图片处理和低频任务。冷启动、运行时限制、供应商绑定和复杂调试也需要评估。
Event / Request → Cloud Function → Managed Services
System View
长期服务
- 持续运行
- 适合稳定高流量
- 控制力强
Serverless Function
- 事件触发
- 弹性按量
- 适合短任务与集成
Designer Lens
“无需管理服务器”降低运维门槛，产品仍然要处理权限、数据、失败和监控。
ServerlessFunction as a ServiceCold Start
08.07
如何选择架构？
架构应匹配当前业务、团队和质量目标，并保留演进空间。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
多租户 SaaSCASE 01
新产品应该直接上微服务吗？
用户正在做什么
三人团队准备验证一个企业知识库产品，预计前半年客户有限。
业务会出什么问题
架构追求复杂和流行会消耗时间，也可能与团队能力和业务规模不匹配。
技术怎样介入
根据交付速度、可靠性、成本、团队边界等 Quality Attribute 做 Trade-off，并允许 Evolutionary Architecture 随业务演进。
产品与设计怎样落地
产品规划中记录当前约束、触发升级的指标和未来可拆分边界。
评估团队数量、发布频率、业务边界、数据一致性、性能、合规和运维能力。架构越分散，独立性越高，系统协作成本也越高。
常见路径是从清晰单体或模块化单体开始，在真实边界、团队或扩容需求出现后逐步拆分。
Current Constraints + Expected Change + Team Capability → Architecture Decision
System View
简单单体
模块边界清晰
局部能力独立
关键业务拆成服务
平台化与规模治理
Designer Lens
讨论技术方案时主动问：当前问题是什么？拆分带来的收益是否覆盖长期成本？
Trade-offEvolutionary ArchitectureQuality Attribute
Chapter Recap
本章小结
- 01架构关注边界、依赖、数据归属和运行方式。
- 02单体可以清晰，模块化单体是重要中间形态。
- 03微服务换来独立发布与扩容，也增加分布式复杂度。
- 04Gateway、负载均衡、服务发现和 Serverless 位于不同架构位置。
Practice
把认知变成一张图
把一个电商系统分别画成单体、模块化单体和微服务三种结构，并标注订单、库存、支付的数据归属。
Quick Check
随堂检查
QUESTION 01
小团队早期产品最需要优先保证什么？
清晰边界和稳定交付通常比过早拆分更重要。
QUESTION 02
Load Balancer 主要解决什么？
负载均衡负责在多个实例之间分配流量。