一、后端架构演进模型
将服务器后端发展分三个阶段：
| 发展阶段 | 核心特征 | 初始复杂度 | 业务复杂后的维护难度趋势 | 当前应用状态 |
|---|---|---|---|---|
| 面向过程脚本 | 以脚本流程为核心 | 简单 | 指数级上升 | 基本不使用 |
| 面向数据库表 | 以数据库表结构驱动设计 | 中等 | 延迟后指数级上升 | 目前市场主流 |
| 面向业务模型 | 以领域模型驱动设计（DDD） | 较高 | 相对可控（通过模型抽象） | DDD+SOA微服务：事件驱动的CQRS读写分离架构 |
二、DDD核心概念与分层架构
1. DDD内核：充血模型
领域驱动设计的革命性在于其采用充血模型。与传统仅包含属性和getter/setter方法的“失血模型”数据对象不同，DDD的领域模型是业务语言的直接反映，不仅承载业务属性，还将具体业务行为（Action）封装在实体对象内部。例如，在生成订单时，判断商品不能为空的业务逻辑应直接定义在订单实体中。
领域模型主要分为三种类型：
- 实体（Entity）：具有唯一标识，内部状态可变，存在生命周期（如订单对象）。
- 值对象（Value Object）：内部值不可变，无生命周期（如地址对象）。
- 服务（Service）：无状态对象，当某个行为或属性无法合适地放入实体或值对象时使用。
建模原则强调在模棱两可时，优先选择简单模型。
2. 四层分层架构
文章引用了Evans《领域驱动设计》书中经典的DDD四层架构，自上而下分别为：
- 用户接口层：处理用户交互与展现。
- 应用层：协调领域对象完成用例，不包含业务逻辑。
- 领域层：包含核心业务逻辑和领域模型（实体、值对象、领域服务）。
- 基础设施层：提供技术实现支持（如数据库、消息队列）。
对于不涉及业务的简单查询操作，允许从应用层直接穿透到基础设施层，DDD本身不限制此类非业务操作的跨层调用
3. 代码模型目录结构
与四层架构对应，推荐的代码目录结构如下：
interfaces(用户接口层)：api：提供面向外部的接口、DTO声明controller：提供HTTP入口（参数校验）
application(应用层)：service（业务层）：业务编排，内部可调用多个领域服务或外部服务。facade：将用户请求委托给一个或多个应用服务进行处理。event：包括两个子目录 publish 和 subscribe，负责事件发布/订阅处理（核心逻辑在领域层）。
domain(领域层)：entity：领域对象，提供转DO方法service：领域服务repository：仓储服务，负责类型转换并调用DAO层
infrastructure(基础设施层)：包含config、common和dao等，提供技术实现细节。
三、防腐层（Anti-Corruption Layer, ACL）
防腐层是一种架构模式，用于在不同语义的子系统之间构建一个隔离层。其核心目的是通过翻译和适配，保护核心应用的设计不受外部系统不良设计或变更的影响，防止外部系统的“腐化”渗透到自身领域。
1. 应用场景
该模式在系统迁移、集成遗留系统或依赖第三方服务时尤为常见。例如，当新系统需要复用遗留系统的功能，或自身特性需调用外部API时，直接依赖外部数据结构会使自身系统变得脆弱。
2. 解决方案与架构
解决方案是在自身应用与外部系统之间引入一个专门的防腐层组件或服务。
- 该层与自身系统的通信，使用自身的数据模型和架构。
- 该层与外部系统的通信，使用外部系统的数据模型和架构。
- 防腐层承担了双向转换的全部逻辑，实现语义隔离。
3. 潜在问题
引入防腐层也带来一些权衡：
- 性能开销：增加系统间通信延迟。
- 维护成本：需要额外开发和维护一个服务层。
- 战略考量：若防腐层是迁移策略的一部分，需规划其是否为永久组件，或在遗留功能迁移完成后将其移除。
DDD除了分层架构的实现之外，还有其他更深层次的架构方案：
领域驱动设计落地【转】 - 小天儿 - 博客园 (cnblogs.com)https://www.cnblogs.com/ningskyer/articles/11582090.html
