DDD 和微服务——数据流和结构
DDD and Microservices - data flow and structure
我正在尝试创建一个简单的博客平台,同时学习更多关于 DDD 和微服务的知识,所以我想问你两个关于这方面的建议:
- 我在我的项目中假设的业务规则之一是只有角色
Publicist
和Administrator
的用户能够创建 posts,但是 postsPublicist
创建的 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 从数据库中检索 post
- 所有业务规则都通过
Posts.Domain
评估,状态更改为Public
Posts
如果一切正常,微服务会更新数据库并通知网关发送Success
HTTP 响应
我的想法...
对于 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 服务应该是“提交”或“发布”。