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

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,bodyText)
        if (this.close && !this.originalPoster.equals(author))
            throw "Discussion is closed."

        return new Post(this.discussionId,postId,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,nextState)
    }            
}

换句话说,从跟踪状态的管道中取出的模型是域服务.域服务中的域逻辑与聚合中的域逻辑一样,也是域模型的一部分 – 两个实现是彼此双重的.

并且您的域的读取模型没有理由不能访问域服务.

相关文章

什么是设计模式一套被反复使用、多数人知晓的、经过分类编目...
单一职责原则定义(Single Responsibility Principle,SRP)...
动态代理和CGLib代理分不清吗,看看这篇文章,写的非常好,强...
适配器模式将一个类的接口转换成客户期望的另一个接口,使得...
策略模式定义了一系列算法族,并封装在类中,它们之间可以互...
设计模式讲的是如何编写可扩展、可维护、可读的高质量代码,...