使用 DDD 方式在微服务中定义 API答案

【问题标题】：Defining APIs in microservices using DDD fashion使用 DDD 方式在微服务中定义 API
【发布时间】：2021-12-17 09:04:58
【问题描述】：

我的示例 DDD 系统包含两个微服务，每个微服务都针对特定上下文定义 - 用户域微服务和房地产域微服务。

我很清楚，聚合根是管理业务实体的单一入口点，例如用户（聚合）可以是 Estate（来自第二个上下文的聚合）的所有者，因此通过 UserAggregate 执行对庄园的管理。

我无法完全理解它在 API 设计和用例方面的应用 - 假设我已经创建了我的个人资料，并且我想添加一个 Estate 作为我的财产。

我如何确定是否应该发送请求到

/user_domain/{user_id}/addNewEstate - 从数据库中检索用户，尝试添加一个执行定义的业务规则的 Estate（最多 5 个 Estate），然后在 EstateService 中复制更改（创建实体并保存它在遗产范围内）

或到

/estate_domain/addnewEstate?userId=sampleId - 它会简单地调用 UserContext 来检查用户是否存在，如果存在，则创建资产（应用业务规则）并将其持久化。

【问题讨论】：

【解决方案1】：

如果我们谈论 DDD，那么用户不能是地产所有者。这是另一个有界上下文。

您可以在 Estate 上下文中引入 Owner 聚合。我不知道遗产的业务任务是什么，但大多数情况下，遗产属于所有者（想想 AirB'n'B），或者它是一个独立的聚合根（想想地籍域） .

然后，所有者可以通过 id 与来自另一个上下文的用户相关联。最有可能的所有者是在用户注册后创建的。用户是登录名。但是所有者意味着通过一些检查，签署协议和通过其他业务规则。

然后端点看起来像 POST /estate_domain/owner/1234/property/

【讨论】：