DDD（1）

在分析一个流程的时候，要抽象几种东西。 1, 状态（主要各阶段的数据, 不变性） 2，行为动作（可以是人触发的，或者系统定时操作） 3，状态的变化 （可以描述为事件） 用户注册更多说法应该存在一个流程， 1，用户注册，需要用户注册资料 2，注册行为一个动作 3，结果是可能失败也可能成功 具体到代码上，如果分得足够细的话。 1. UserRegRequest 封装用户注册请求 2，interface UserRegister{} 封装行为过程 3. UserReqResult 注册结果（失败或者成功） UserRegister 处理中，可能包括数据库的交互（ Repository, Entity 抽象），与其它 Domain 的交互，比如 Register 成功的情况 raise RegisteredEvent 去通知另外一个 Notification Domain 发送一封邮件。 具体实践过程，为了偷懒，很多时候一个类可能代表了多个角色，最常见的我们写 Spring，Entity 代替了 DomainClass （真正设计应该完全分开，Domain 类应该包括业务处理）。即使如此，也应该清楚这个类在什么地方应该充当什么角色。遗憾的是，一些开发人员，完全脱离业务，只看到一个类封装了什么字段。 DDD 参考代码，经典的 CargoTracker 程序，DDD 原书自带的。 https://github.com/citerus/dddsample-core （使用了 Spring 作为 Glue ） 另外，Java EE /Jakarta EE 标准也维护了一个版本。 https://github.com/eclipse-ee4j/cargotracker DDD 原书没有在代码组织上过多的深挖，基本是三层结构的演变，定义了，interfaces, applicaiton, domain, infrastruture 四层结构。 真正能够很好揣述 DDD 在代码结构上的规划，应该用后来演变出来的 Onion 和 Hexagonal 架构。第一次看到 Hexagonal 系统用 Driving 和 Driven 将整个应用体系一分为二的时候，很多东西感觉清晰了。 https://reflectoring.io/spring-hexagonal/