领域驱动与六边形架构落地

它解决什么问题

当业务逻辑与数据库、HTTP 框架深度耦合时，常出现改一个需求要动多处代码、业务规则难以独立测试的情况——最贵的代码是核心业务被技术细节绑架。这类系统里，领域知识散落在 Service、Controller 与 DAO 之间，换框架或升级数据库都要重写大量业务逻辑，单元测试不得不启动整个容器才能验证简单规则。

技能如何工作

作为业务建模架构师，它遵循两个核心原则：用 DDD 梳理业务边界，用六边形架构保护核心领域。具体步骤：

• 划限界上下文：按业务能力拆分（如订单、库存、用户），每块维护独立模型，不共享 mutable 实体
• 建领域模型：用实体、值对象、聚合表达业务规则，不放技术字段
• 定义端口：核心需要的存储、发送、查询等能力先抽象为接口，核心模块零框架依赖
• 写适配器：边缘层用 JPA/REST/Redis 实现端口
• 依赖朝内：编译依赖统一指向核心，框架被挡在边界外

同时提供检查清单：核心是否零框架 import？边界是否清晰？端口是否只暴露核心所需？业务逻辑能否脱离 DB/Web 纯单元测试？

适用边界与注意点

• 避免贫血模型：实体只有 getter/setter、逻辑全在 Service，会让 DDD 退化为 CRUD
• 拒绝过度拆分：小项目硬上全套 DDD，复杂度会超过收益
• 防范端口泄漏：适配器不能把技术异常或类型透传进核心
• 架构选型需结合团队规模与业务复杂度，落地时要参考官方文档和团队规范