除Clean Architecture外，单体软件还有哪些值得了解的软件架构？

Clean Architecture本身属于分层架构结合依赖倒置原则的衍生变体，除此之外以下架构都经过大量生产实践验证，适合不同场景的单体项目：

• 三层架构：最经典的通用单体架构，核心划分为表现层、业务逻辑层、数据访问层，层间遵循单向向下依赖的规则，职责边界清晰，实现、调试、维护成本极低，是绝大多数中小型单体项目的首选架构，也是很多复杂架构模式的基础原型。
• DDD分层架构：领域驱动设计配套的标准架构，通常划分为用户接口层、应用层、领域层、基础设施层，核心特点是将所有核心业务逻辑收敛到无外部依赖的领域层，避免业务逻辑被外围实现逻辑侵蚀，适合业务复杂度高、迭代周期长的中大型单体项目。
• 洋葱架构：Clean Architecture的核心参考原型，同样属于依赖倒置类架构，以同心圆结构划分层级，从内到外依次是领域模型、领域服务、应用服务、外层适配器（包含UI、数据库、第三方服务调用等），所有依赖必须从外层指向内层，内层完全不感知外层实现细节，可测试性、可移植性极强，适合需要长期维护、多端适配的单体项目。
• 模块化单体架构：介于传统单体和微服务之间的架构模式，将单体应用按照业务域拆分为多个独立的高内聚低耦合模块，模块间仅能通过明确定义的公共接口交互，禁止直接访问内部实现，既保留了单体部署简单、内部调用无网络开销的优势，又具备类似微服务的边界清晰、支持多团队并行开发的特性，适合团队规模中等、不想承担微服务复杂运维成本的项目。
• 事务脚本架构：最轻量的单体架构模式，每个业务请求对应一个独立的事务脚本，直接处理请求、操作数据库，没有额外的分层和抽象，开发速度极快，适合逻辑简单、迭代需求少的小型单体项目或者内部工具类项目。
• 活动记录架构：和ORM模型深度绑定的架构，数据库表对应实体类，实体类本身封装了数据访问逻辑和相关业务逻辑，调用方式简单直观，很多Web开发框架的默认推荐架构都属于这一类，适合业务逻辑不复杂、数据模型相对固定的单体项目。

内容的提问来源于stack exchange，提问作者Abdelkrim