软件设计：在约束中构建可演进的系统

软件设计不是画出完美的图，而是在需求、时间、成本和变化之间做出一系列可解释的权衡。

一、软件设计到底在设计什么

软件设计是把需求转化为可实现、可维护、可演进系统的过程。它不只是画 UML 图，也不只是选框架，而是回答几个核心问题：

• 系统边界在哪里？
• 模块如何划分，各自承担什么职责？
• 模块之间如何通信，接口是什么？
• 数据如何组织、存储和流动？
• 当需求变化时，哪些部分需要改，哪些部分可以保持稳定？

软件设计通常分为三个层次：架构设计关注系统整体结构和关键决策；模块设计关注模块职责与依赖关系；详细设计关注类、函数、数据结构和算法。三者不是割裂的，而是从粗到细、不断细化的过程。

二、设计的目标：质量属性

好的设计不是“看起来漂亮”，而是满足质量属性。常见的质量属性包括：

• 可维护性：修改一处，不会引发连锁反应；
• 可扩展性：新增功能时，尽量少改已有代码；
• 可测试性：业务逻辑容易脱离框架和数据库进行测试；
• 可靠性：异常、超时、并发下仍能正确工作；
• 性能与可伸缩性：在预期负载下保持可接受延迟；
• 安全性：权限、隐私、输入校验、审计；
• 可观测性：日志、指标、追踪能帮助定位问题；
• 成本：开发成本、运维成本、云资源成本。

这些目标往往互相冲突。提高性能可能增加复杂度，追求扩展性可能拖慢交付。软件设计的本质，就是在具体约束下做权衡。

三、软件设计的基本流程

一个可落地的设计流程通常包括以下步骤：

1. 理解需求与约束：功能需求、非功能需求、预算、工期、团队能力、合规要求。
2. 识别核心领域：找到业务中最关键的概念和规则，而不是先想数据库表。
3. 划分模块与边界：按职责和变化频率切分，避免“大泥球”。
4. 定义接口与数据契约：明确输入、输出、错误和版本策略。
5. 选择架构风格：分层、六边形、微服务、事件驱动，或模块化单体。
6. 设计数据与存储：数据模型、一致性、事务、索引、迁移和隐私。
7. 处理横切关注点：日志、鉴权、配置、监控、异常处理。
8. 原型与评审：用最小原型验证关键风险。
9. 文档化与演进：记录关键决策，随反馈持续调整。

四、核心设计原则

原则不是教条，而是帮助判断的透镜。

• 高内聚、低耦合：相关的东西放在一起，不相关的东西减少依赖。
• 单一职责：一个模块只对一个变化原因负责。
• 开闭原则：对扩展开放，对修改关闭。
• 接口隔离：不要让调用方依赖它不需要的方法。
• 依赖倒置：高层策略不依赖低层实现，二者都依赖抽象。
• KISS、YAGNI、DRY：简单优先，不提前实现，不重复知识。
• 关注点分离：业务逻辑、输入输出、持久化分开。

下面是一个依赖倒置的极简示例：

from abc import ABC, abstractmethod

class UserRepository(ABC):
    @abstractmethod
    def find_by_id(self, user_id: str): ...

class UserService:
    def __init__(self, repo: UserRepository):
        self.repo = repo

    def get_user(self, user_id: str):
        return self.repo.find_by_id(user_id)

UserService 不关心数据来自 MySQL、Redis 还是 HTTP API，它只依赖抽象接口。这样业务逻辑更容易测试，也更容易替换基础设施。

五、架构风格与选型

常见架构风格各有适用场景：

• 分层架构：适合大多数业务系统，结构清晰，但容易层层调用。
• 六边形架构 / 端口适配器：业务核心与外部技术解耦，适合复杂领域。
• 模块化单体：一个部署单元，内部按模块严格隔离，适合中小团队。
• 微服务：独立部署、独立扩展，但带来分布式复杂度、运维成本和数据一致性挑战。
• 事件驱动：通过事件解耦，适合异步、高吞吐场景，但追踪和调试更难。
• CQRS：读写模型分离，适合读写负载差异大的系统，但增加复杂度。

选型时不要默认微服务。对多数团队而言，模块化单体往往是更务实的起点：先保证边界清晰，再根据压力拆分。

六、模块与接口设计

接口是模块之间的契约。好的接口应该：

• 名称表达意图，而不是实现细节；
• 参数少而明确；
• 返回值稳定，错误可预期；
• 尽量幂等，便于重试；
• 有版本策略，避免破坏调用方。

一个清晰的分层目录可以这样组织：

src/
  domain/         # 领域模型与业务规则
  application/    # 用例与流程编排
  infrastructure/ # 数据库、消息、外部服务
  interfaces/     # HTTP、CLI、定时任务

依赖方向应指向内层：interfaces 依赖 application，application 依赖 domain，infrastructure 实现 domain 或 application 定义的接口。这样业务核心不会被框架和数据库绑架。

七、数据设计

数据设计常被低估，但它往往决定系统的长期形态。

• 数据模型：先理解领域，再设计表；避免让数据库结构反向扭曲业务。
• 一致性：明确强一致、最终一致和补偿事务的边界。
• 事务：事务尽量短，避免跨服务大事务。
• 索引：根据查询模式设计，而不是盲目加索引。
• 迁移：数据库变更要可回滚、可灰度、可兼容旧代码。
• 隐私与合规：最小收集、加密存储、访问审计、定期清理。

八、设计模式：工具而非目标

设计模式是前人经验的总结，常见的有工厂、策略、观察者、适配器、仓储、依赖注入等。它们能解决特定问题，但不应为了“用模式”而增加抽象。

判断是否需要模式，可以问三个问题：当前是否有明确痛点？引入后是否降低理解成本？未来变化是否真的会发生？如果答案是否定的，简单直接的代码往往更好。

九、文档与沟通

设计需要被团队理解和执行。有效文档包括：

• C4 模型：从系统上下文、容器、组件到代码，分层表达架构；
• ADR 架构决策记录：记录背景、选项、决策和后果；
• 接口文档：请求、响应、错误码、示例；
• 运行手册：部署、监控、告警、故障处理。

文档不必追求大而全，关键是记录“为什么这样设计”和“边界在哪里”。

十、评审与验证

设计评审不是走过场，而是提前发现风险。评审时重点关注：边界是否清晰、依赖是否合理、数据一致性是否可控、失败场景是否处理、安全与权限是否到位。

验证手段包括原型、单元测试、集成测试、契约测试、压测和混沌实验。可观测性也应在设计阶段考虑：日志、指标、追踪、告警，都是系统的一部分。

十一、演进式设计

软件设计不是一次性活动。需求会变，团队会变，技术也会变。演进式设计强调：

• 小步重构，持续改善；
• 管理技术债，而不是无限累积；
• 增量交付，尽快获得反馈；
• 保留清晰的边界，让替换和扩展成为可能；
• 接受不完美，但让关键决策可解释、可回退。

十二、常见误区

• 过度设计：为不确定的未来增加大量抽象；
• 过早优化：没有数据支撑就优化性能；
• 忽视非功能需求：只关注功能，忽略安全、性能和可观测性；
• 没有边界：模块随意调用，最终变成大泥球；
• 文档缺失：关键决策只留在个别人脑中；
• 忽略团队能力：设计再优雅，团队维护不了也是失败。

十三、结语

软件设计是一门关于权衡的工程学科。它不需要一开始就完美，但需要清晰的边界、稳定的接口、合理的抽象和持续的反馈。少量代码可以表达核心思想，但真正决定系统质量的，是设计背后的思考：为什么这样分、为什么这样依赖、为什么现在不做更多。

好的设计让系统在变化中保持可控，让团队在协作中保持高效。它不是追求复杂，而是用恰当的结构，承载不断生长的需求。