将数据从UI添加到不同的微服务中

Question

假设您有一张用户登记表，其中您填写了以下表单:姓名、姓氏、年龄、地址、首选的通信方式: Sms、电子邮件(无线电按钮)。

你有两个微型服务：

• UserManagement服务
• 通信业务

注册用户时，我们应该在两个服务中创建两个聚合: UserManagementContext中的用户和通信中的UserCommunicationSettings。

我可以想出三种方法来实现这一目标：

1. 从UI执行两个不同的请求。如果其中一个失败了呢？
2. 将所有这些数据放在用户中，然后用所有这些数据引发集成事件，在CommunicationContext中捕获它。Fat事件、集成事件不应该包含域数据，而应该只包含aggreagates的ids。
3. 将消息放入队列中，这样两个上下文都会有适配器来获取所需的信息。

拆分这些数据并保存信息的最佳选择是什么？

Answer 1

正如您在存储通信设置时提到的那样，假设通信数据应该不是UserManagement服务有限上下文的一部分。

我在另一个答案中看到了方法3提出的几个问题。虽然我认为最初答案中的第三种方法与我的答案非常相似。

• 如果增加了更多的通信模式呢？当然，它应该只会导致通信服务的改变，而不是UserManagement服务。SRP。通信设置MS应该将所有与通信设置相关的数据存储在自己的数据库中。
• 如果用户只更新他的通信设置首选项怎么办？为什么用户管理服务要承担这方面的负担？在我们的例子中，通信设置的改变应该只是触发相应的微服务，即通信服务的更改。
• 我发现最好使用一些自然键来识别和关联跨微服务的实体，而不是由DB生成的内部I。考虑到明天您决定使用完全不同的策略为UserManagement服务创建用户的“id”，例如非数字id、不同的id生成算法等等。我希望其他微服务不受任何此类决定的影响。

提出的方法：

• 在体系结构中包括API网关。前端总是与API网关对话。
• API向消息队列(如RegisterUser )发送命令，以供感兴趣的微服务使用。
• 如果您希望保持体系结构的简单性，可以使用任何感兴趣的微服务来发布包含所有数据的单一消息。如果严格地希望单个微服务只查看其相关数据，则根据消费服务所期望的唯一数据结构创建消息队列。

​

​

Answer 2

从UI执行两个不同的请求。如果其中一个失败了呢？

我觉得这样不行。你将以不一致的状态结束。

我赞成接近3#：

1. 用户被持久化(创建)到用户存储中。
2. UserRegistered事件被四处发送，其中包含用户的ID。
3. 所有感兴趣的各方都处理UserRegistered事件。

我会选择slim事件，因为您的服务可能需要不同的用户数据，最好是让他们自己获取这些数据，而不是把所有的东西都放到事件中。