user-interface - 用户界面如何知道允许对聚合根执行哪些命令？

Question

UI 与域解耦，但 UI 应尽量不让用户发出肯定会失败的命令。
考虑以下示例(伪代码):

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 示例)。但是我不喜欢将业务逻辑移到我的域模型之外的想法，并将其放在读取端和写入端都可以使用的服务中。

也许这不是最好的例子，但由于聚合根基本上是一个一致性边界，我们知道我们需要防止其生命周期中的无效状态转换，并且在每次转换到新状态时，某些操作可能会变得非法，反之亦然反之。那么，用户界面如何知道什么是允许的，什么是不允许的？我的选择是什么？我应该如何处理这个问题？你有什么例子可以提供吗？

Answer 1

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.

我认为这里最好的答案是“克服它”。我得到它;因为在聚合根中包含业务逻辑是文献告诉我们要做的。但是，如果您继续重构，识别常见模式并分离关注点，您会发现实体实际上只是在围绕对 state 的引用和 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)
    }            
}

换句话说，从跟踪状态的管道中提取出来的模型是一个域服务。域服务中的域逻辑与聚合中的域逻辑一样是域模型的一部分——这两种实现是相互关联的。

并且您的域的读取模型没有理由不应该访问域服务。