DDD和微服务-数据流和结构

Question

我正在尝试创建一个简单的博客平台，同时了解有关DDD和微服务的更多信息，因此我想在此上下文中向您询问两个建议：

< li >我在我的项目中假设的一个业务规则是，只有角色为< code > publicis 和< code>Administrator的用户才能创建帖子，但是由< code > publicis 创建的帖子在发布之前必须首先得到< code>Administrator的批准。在我的理解中，这是<代码>帖子的一部分。域，所以在< code>Post聚合(同时也是实体)中，我将Post状态的更改封装到像< code > SetPublishedStatusBy 这样的方法中，这些方法将< code >用户(请求者)数据作为参数，并评估上述规则(创建域事件)。然而，现在我有些怀疑关于请求者的信息是否真的是< code >帖子的一部分。域。也许应该在不同的地方评估请求者，比如< code >帖子。API或其他一些服务，然后在完成后不带参数地调用< code>SetPublishedStatus？ < li >让我们继续讨论以上内容。除了< code>Posts微服务，我还在开发独立的< code>Users微服务，负责存储用户，并为< code>Administrator提供一些管理用户的工具。当用户想要发布一个新帖子时，什么是合适的数据流呢？我可以这样想象:

< li >客户端向网关发送带有发布ID的< code>PublishPost命令 < li >网关验证来自HTTP请求的用户(可能通过带有JWT的cookie完成) < li >网关向< code > post 微服务发送< code>PublishPost命令 < Li > < code > post 微服务调用< code>Users微服务从DB获取相关用户数据 < Li > < code > post 微服务按ID从数据库中检索post < li >所有业务规则都通过< code >帖子进行评估。域，并且状态更改为< code >公共 < Li > < code > post 如果一切正常，微服务将更新数据库，并通知网关发送< code >成功 HTTP响应

Answer 1

我的想法...

对于DDD，在与领域专家讨论时，最好从领域的泛在语言中获得指导。

“SetPublishedStatusBy”一词可能不会出现在讨论中。

我认为这次讨论最有可能的结果是：

• 管理员并发布帖子。
• 公关人员可以提交管理员在发布之前必须批准的帖子。
• 管理员可以批准已由公关人员提交的已提交帖子，这将导致该帖子被发布。
• 管理员可以拒绝提交的帖子。

我的帖子聚合最终会看起来像：

class Post
{
    void Submit()
    {
        this.Status = Submitted;
    }
    void Publish()
    {
        this.Status = Published;
    }
    void Approve()
    {
        if (this.Status != Submitted) throw "This post is not pending approval.";
        this.Status = Published;
    }
    void Reject()
    {
        if (this.Status != Submitted) throw "This post is not pending approval.";
        this.Status = Rejected;
    }
}

创建帖子时，UI将根据上下文在API中调用Publish或Submit。然后，API将检查当前用户是否可以执行请求的发布或提交。

其他两个选项：

1. 引入一个名为Post请求的聚合，公关人员有权创建它，并且只有在管理员批准时才能创建帖子。
2. 如果您希望规则更具动态性，即用户只需点击“发布”，无论他们是公关人员还是管理员，然后根据当天的规则，结果是发布的帖子或提交的帖子，那么您需要在您的API和可以与用户服务交互的Aggregate之间建立一个编排/传奇/任务层，以决定对帖子服务的第一次调用应该是“提交”还是“发布”。