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

Question

我正在尝试创建一个简单的博客平台，同时了解有关 DDD 和微服务的更多信息，所以我想请教您在这方面的两个建议：

1. 我在项目中假设的一个业务规则是，只有角色Publicist 和Administrator 的用户才能创建帖子，但Publicist 创建的帖子必须先得到Administrator 的批准才能发布公开。据我了解，这是Posts.Domain 的一部分，因此在Post 聚合（同时也是实体）中，我将更改帖子的状态封装为SetPublishedStatusBy 之类的方法，该方法将User（请求者）数据作为参数并评估上述规则（+ 创建域事件）。但是现在我怀疑有关请求者的信息是否真的是Posts.Domain 的一部分。也许应该在不同的地方评估请求者，例如 Posts.API 或其他一些服务，然后在完成后调用 SetPublishedStatus 而不使用参数？
2. 让我们坚持上面的内容。尽管有Posts 微服务，我还在开发独立的Users 微服务，负责存储用户并为Administrator 提供一些工具来管理它们。当用户想要发布新帖子时，正确的数据流是什么？我会通过以下方式来想象：

• 客户端向网关发送 PublishPost 命令和 post ID
• 网关通过 HTTP 请求对用户进行身份验证（可能通过带有 JWT 的 cookie 完成）
• 网关向Posts微服务发送PublishPost命令
• Posts微服务调用Users微服务从DB获取相关用户数据
• Posts 微服务按 ID 从 DB 检索帖子
• 所有业务规则都通过Posts.Domain 进行评估，状态更改为Public
• 如果一切正常，Posts 微服务会更新数据库并通知网关发送Success 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. 引入一个名为 PostRequest 的聚合，公关人员有权创建并且只有在管理员批准后才能创建帖子。
2. 如果您希望规则更加动态，即用户只需点击“发布”，无论他们是公关人员还是管理员，然后结果是发布的帖子或提交的帖子，具体取决于当天的规则，那么你会想要在你的 API 和聚合之间有一个编排/传奇/任务层，它可以与用户服务交互来决定对 Posts 服务的第一次调用应该是“提交”还是“发布”。