从零设计软件开发系统的分层架构与模块划分
近期趋势：分层架构仍是设计起点，模块化拆分成为标配
在近期的技术社区讨论中，从零构建一套软件开发系统时，分层架构与模块划分始终是首批被确定的骨架。无论是面向企业级后台、移动端服务，还是物联网边缘计算，开发者普遍将系统拆分为“表现层、业务逻辑层、数据访问层”三层，并在每层内进一步按功能域或业务域切分子模块。这一做法源于对维护成本、团队协作效率的长期观察：没有清晰分层，后期重构几乎无法避免。
同时，微服务架构和领域驱动设计（DDD）的普及，推动模块划分向更细粒度演进。一些团队选择“垂直切片”而非纯水平分层——即每个业务能力独立包含自己的控制器、服务和仓储。这种混合模式近来被较多中型项目采用，因为它能兼顾分层隔离与快速迭代。
行业背景：从单体到分布式，分层与模块的设计取舍
行业背景呈现两条并行路线：一是存量系统的改造需求，二是新系统从零搭建的需求。两者都绕不开分层与模块的界定。常见痛点是“层间职责模糊”——比如在业务层中直接编写SQL，或把大量业务逻辑塞入表现层。导致这类问题的原因通常包括：最初未定义模块之间的依赖方向、未规定跨层通信的契约（如DTO或接口定义），以及缺少模块内聚性检查的机制。
从行业实践看，成熟的分层架构通常包含以下核心模块：
- 表现层模块：负责用户交互、输入校验、会话管理；原则上不包含业务规则。
- 应用服务层模块（可选）：协调多个领域服务，处理事务边界和权限判断。
- 领域/业务层模块：封装核心业务逻辑，是变更最频繁、测试优先级最高的部分。
- 基础设施层模块：数据持久化、外部接口调用、消息队列、缓存等通用能力。
- 共享/工具模块：跨层公共组件（如异常定义、枚举、常量、统一返回结构）。
模块之间通过依赖倒置原则（依赖抽象而非具体实现）保持松散耦合。例如业务层只引用数据访问层定义的接口，而不直接依赖某一种数据库驱动。
用户关注点：分层粒度、模块拆分边界、可测试性
从零开始设计时，用户最常关心三个问题：
- 每一层应该多“厚”？——层过厚会导致复用困难，层过细则增加上下级通信开销。经验范围是：同类操作（如查询、命令）统一入口，但不要将不同业务域的处理强塞进同一个服务类。
- 模块按什么切分？——常见的判断方法：如果两个功能经常被一起修改，或者它们访问同一组数据表，则更适合放在同一模块；反之，若它们面向不同的用户角色或变化频率差异大，则应拆分。
- 如何保证可测试性？——分层本意是让每一层可独立测试。模块划分时应确保业务层不依赖具体持久化实现（通过接口注入），基础设施层不包含业务判定。用户往往需要定义清晰的“测试替身”策略，例如为数据访问层编写内存实现。
注意：实际项目中，超过80%的耦合问题源于跨模块的直接引用或共享可变状态。建议在模块边界上只暴露接口，且只允许单向依赖。
可能影响：技术选型、团队结构、演进成本
分层与模块划分的决策会在后续开发中产生连锁影响：
| 影响维度 | 典型表现 |
|---|---|
| 技术选型 | 选择ORM、消息中间件、框架时，需匹配各层的职责边界。例如ORM如果直接在业务层暴露Entity，容易导致层间泄漏。 |
| 团队结构 | 如果按技术层分配（前端组、后端组、数据组），则模块可能按层切分；如果按业务域分配，则模块通常跨层垂直组织。 |
| 演进成本 | 初期分层过粗，后期拆分难度高；分层过细，初期开发效率下降。多数团队会在完成第一个核心功能后复盘调整，而非一次性定型。 |
此外，模块划分不合理会导致“循环依赖”或“上帝模块”——一个模块耦合了本应分散在多处的逻辑。后续重构时往往需要引入事件驱动或依赖注入容器来解开。
后续观察：设计模式沉淀与低代码影响
可以持续关注两个方向：一是分层架构与领域驱动设计（DDD）的模式沉淀——越来越多的开源脚手架（如ABP、JHipster）提供了“模块化生成”能力，它们按照聚类规则（比如每个聚合根一个模块）自动生成代码骨架。二是低代码/无代码平台对传统分层设计的影响：这类平台往往将表现层和部分业务层合并为配置界面，但底层仍然需要手工定义数据模型和业务规则——因此基础分层思想不会消失，但模块划分的粒度可能从“类级别”变为“业务单元级别”。
未来，随着AI辅助代码生成工具的进步，从自然语言描述中自动推导出分层结构和模块边界或许成为可能，但当前阶段，理解分层原理并亲手划分仍是系统设计的必修课。