@
mikulch 在分析一个流程的时候,要抽象几种东西。
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/cargotrackerDDD 原书没有在代码组织上过多的深挖,基本是三层结构的演变,定义了,interfaces, applicaiton, domain, infrastruture 四层结构。
真正能够很好揣述 DDD 在代码结构上的规划,应该用后来演变出来的 Onion 和 Hexagonal 架构。第一次看到 Hexagonal 系统用 Driving 和 Driven 将整个应用体系一分为二的时候,很多东西感觉清晰了。
https://reflectoring.io/spring-hexagonal/