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

Question

我正在尝试创建一个简单的博客平台，同时学习更多关于 DDD 和微服务的知识，所以我想问你两个关于这方面的建议：

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

客户端向网关发送带有 post ID 的 PublishPost 命令
网关根据 HTTP 请求对用户进行身份验证（可能通过 cookie 和 JWT 完成）
网关向 Posts 微服务发送 PublishPost 命令
Posts微服务调用Users微服务从DB
Posts 微服务通过 ID
所有业务规则都通过 Posts.Domain 评估，状态更改为 Public
Posts 如果一切正常，微服务会更新数据库并通知网关发送 Success HTTP 响应

Answer 1

我的想法...

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

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

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

管理员和发布 post.
公关人员可以提交管理员必须批准的post在发布之前。
管理员可以批准一个已提交的post，这将导致post 正在发布中。
管理员可以拒绝 提交post。

我的 Post 聚合最终看起来像这样：

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;
    }
}

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

另外两个选项：

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

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

DDD and Microservices - data flow and structure

design-patterns

architecture

microservices

domain-driven-design

domain-model