前一篇文章介绍了domain object。这篇文章写一下具体的例子。
假设我们要实现一个账户管理的密码修改功能。
大致需求
账号通过邮箱地址来识别(identifier)
- 密码不能为空
- 密码必须加密(这个功能暂不实现)
修改密码
- 修改密码时必须输入旧密码,旧密码输入正确后才可更改密码。
从aggregate开始
其实建模是一个过程,而且可能是程序设计里比较难有容易被忽略的过程。就像很多侦探片里的推理一样,推理很难,但往往侦探片只会告诉你答案,而不是告诉你如何推理的。很抱歉我这里也讲不了建模的过程,这会是另一个话题。但大概我们会想到如下的model。
Account aggregate
Account (entity, Account aggregate的root)
因为密码可以更改可以理解为mutable,密码变化后,不代表账号就变成了另一个账号。所以把它定义成entity。
AccountId (value object)
账号id生成后就不可变了。
Password (value object)
密码设置后,密码本身是不可变的。
更改账号密码应该理解为,用新密码换掉账号的旧密码。而非旧密码本身做了变化。
然后对应aggregate,会有AggregateRepository
具体的实现
Account
public class Account {
private AccountId accoun