考虑以下示例(伪代码)：
DiscussionController
@Security(is_logged)
@Method('POST')
@Route('addPost')
addPostToDiscussionAction(request)
discussionService.postToDiscussion(
new PostToDiscussionCommand(request.discussionId, session.myUserId, request.bodyText)
)
@Method('GET')
@Route('showDiscussion/{discussionId}')
showDiscussionAction(request)
discussionWithAllThePosts = discussionFinder.findById(request.discussionId)
canAddPostToThisDiscussion = ???
// render the discussion to the user, and use `canAddPostToThisDiscussion` to show/hide the form
// from which the user can send a request to `addPostToDiscussionAction`.
renderDiscussion(discussionWithAllThePosts, canAddPostToThisDiscussion)
PostToDiscussionCommand
constructor(discussionId, authorId, bodyText)
DiscussionApplicationService
postToDiscussion(command)
discussion = discussionRepository.get(command.discussionId)
author = collaboratorService.authorFrom(discussion.Id, command.authorId)
post = discussion.createPost(postRepository.nextIdentity(), author, command.bodyText)
postRepository.add(post)
DiscussionAggregate
// originalPoster is the Author that started the discussion
constructor(discussionId, originalPoster)
// if the discussion is closed, you can't create a post.
// *unless* if you're the author (OP) that started the discussion
createPost(postId, author, bodyText)
if (this.close && !this.originalPoster.equals(author))
throw "Discussion is closed."
return new Post(this.discussionId, postId, author, bodyText)
close()
if (this.close)
throw "Discussion already closed."
this.close = true
isClosed()
return this.close
>用户转到/ showDiscussion / 123,他看到与< form>的讨论.他可以从中提交新帖子,但仅在讨论未结束或当前用户是谁开始讨论时才提交.
>或者,用户转到/ showDiscussion / 123,它将作为REST-as-in-HATEOAS API呈现.仅当讨论未关闭或经过身份验证的用户是谁开始讨论时,才会提供指向/ addPost的超媒体链接.
如何将这些知识提供给UI？
我可以将其编码到读取模型中,
canAddPostToThisDiscussion = !discussionWithAllThePosts.discussion.isClosed
&& discussionWithAllThePosts.discussion.originalPoster.id == session.currentUserId
但后来我需要维护这个逻辑并使其与写模型保持同步.这是一个相当简单的例子,但随着聚合的状态转换变得更加复杂,它可能变得非常困难.我想将我的聚合图像作为状态机,以及它们的工作流程(如RESTBucks示例).但我不喜欢将业务逻辑移到我的域模型之外的想法,并把它放在读取端和写入端都可以使用的服务中.
也许这不是最好的例子,但由于聚合根基本上是一致性边界,我们知道我们需要在其生命周期中防止无效状态转换,并且在每次转换到新状态时,某些操作可能变为非法和副反之亦然.那么,用户界面如何知道允许与否？我有什么选择？我该如何处理这个问题？你有什么例子可以提供吗？
How can I provide that knowledge into the UI?
最简单的方法可能是分享域模型对UI可能性的理解.塔达
这是一种思考它的方法 – 在抽象中,所有写模型逻辑都具有相当简单的外观形状.
{
// Notice that these statements are queries
State currentState = bookOfRecord.getState()
State nextState = model.computeNextState(currentState, command)
// This statement is a command
bookOfRecord.replace(currentState, nextState)
}
这里的关键思想：记录册是国家权威;其他人(包括“写模型”)正在使用陈旧的副本.
模型表示的是一组约束,可确保满足业务不变性.在系统的生命周期中,可能存在许多不同的约束集,因为对业务的理解会发生变化.
写入模型是在替换记录簿中的状态时当前强制执行约束的权限.其他人都在使用陈旧的副本.
陈旧是要牢记的;在分布式系统中,您执行的任何验证都是临时的 – 除非您锁定状态并锁定模型,否则可以在邮件处于运行状态时更改.
这意味着您的验证无论如何都是近似的,因此您不必过于担心您的所有细节都是正确的.您假设状态的陈旧副本大致正确,并且您当前对模型的理解大致正确,并且如果命令在给定这些前置条件的情况下有效,则检查它是否足以发送.
I don’t like the idea to move that business logic outside my domain model, and put it in a service that both the read side and write side can use.
我认为这里最好的答案是“克服它”.我知道了;因为在聚合根中包含业务逻辑是文献告诉我们要做的事情.但是如果你继续重构,识别常见模式并分离问题,你会发现实体实际上只是围绕对状态和functional core的引用进行管道调整.
AggregateRoot {
final Reference<State> bookOfRecord;
final Model<State,Command> theModel;
onCommand(Command command) {
State currentState = bookOfRecord.getState()
State nextState = model.computeNextState(currentState, command)
bookOfRecord.replace(currentState, nextState)
}
}
我们在这里所做的就是采用“构造下一个状态”逻辑,我们过去常常将其分散到AggregateRoot中,并将其封装到一个单独的责任边界中.这里,它特定于根本身,但是等效的重构它将它作为参数传递.
AggregateRoot {
final Reference<State> bookOfRecord;
onCommand(Model<State,Command> theModel, Command command) {
State currentState = bookOfRecord.getState()
State nextState = model.computeNextState(currentState, command)
bookOfRecord.replace(currentState, nextState)
}
}
换句话说,从跟踪状态的管道中取出的模型是域服务.域服务中的域逻辑与聚合中的域逻辑一样,也是域模型的一部分 – 两个实现是彼此双重的.
并且您的域的读取模型没有理由不能访问域服务.