使用DDD方式定义微服务中的API
我的示例DDD系统包含两个微服务，每个微服务都为特定上下文定义——用户域微服务和房地产域微服务。
我很清楚聚合根是管理业务实体的单一入口点，例如用户（聚合）可以是属性的所有者（来自第二个上下文的聚合），因此属性的管理是通过UserAggregate执行的。
我不能完全理解的是它在API和用例设计方面是如何应用的——假设我已经创建了我的个人资料，并且我想添加一个房地产作为我的归属。
如何确定是否应将请求发送至
/user_domain/{user_id}/addNewEstate-从数据库中检索用户，尝试添加一个执行定义的业务规则的Estate（例如，最多5个Estate），然后在EstateService中复制更改（创建实体并将其保存在Estate上下文中）
或者去
/estate_domain/addnewEstate？userId=sampleId-它将简单地调用UserContext来检查用户是否存在，如果存在，则创建属性（应用业务规则）并将其持久化。
共有1个答案
如果我们谈论DDD，那么用户就不能是房地产所有者。这是另一个有界的上下文。
您可以在地产上下文中引入所有者集合。我不知道房地产的业务任务是什么，但大多数情况下，当房地产属于所有者时(想想AirB'n'B)，或者当它是一个独立的聚合根时(想想cadaster domain)。
所有者可以通过id从另一个上下文与用户相关联。很可能所有者是在用户注册后创建的。用户是登录名。但是所有者意味着通过一些检查、签署协议和传递其他业务规则。
那么endpoint看起来像POST /estate_domain/owner/1234/property/
-
我正在尝试创建一个简单的博客平台，同时了解有关DDD和微服务的更多信息，因此我想在此上下文中向您询问两个建议： < li >我在我的项目中假设的一个业务规则是，只有角色为< code > publicis 和< code>Administrator的用户才能创建帖子，但是由< code > publicis 创建的帖子在发布之前必须首先得到< code>Administrator的批准。在我的理解
-
我有两个微服务和调用来更新数据，然后插入另一个数据，但让我们考虑一下 失败，然后我们需要回滚由 更新的数据，否则我们将处于不一致的状态。 我也经历了佐贺patterns.will它满足了这种矛盾 谁能为此提出更好的解决方案？
-
得到了一个使用:< code>spring-boot、< code>spring-cloud、< code>postgresql作为微服务系统的项目。 有 2 个服务，比如 SA 和 SB，它们分别在 2 个 RDBMS 数据库上运行，比如 DA 和 DB。 现在，有一个包含2个子步骤的操作: Http客户端会向服务SA发出请求，将记录保存到中。 然后，SA向服务SB发送请求，将记录保存到中。 作
-
我有一个基于spring-boot的mircroservice环境，在这里我使用zipkin服务器、discovery-server（eureka）和Config-Server。现在我有了一个REST微服务，它向zipkin服务器发送日志，需要这个微服务来使用Discovery-Server解析zipkin服务器的位置。 下面是我在REST微服务的application.properties中的z
-
Appium 的 iOS 版本的后端用的是Facebook's WebDriverAgent。该后端是基于苹果公司的 XCTest 框架，所以也有所有XCTest 框架已知的问题。其中有些问题我们正在设法解决，有一些在现阶段可能无法解决。本文中描述的方法已经能够使您完全掌握在设备上如何构建、管理和运行WDA。通过这种方式，您可以在CI环境中对您的自动化测试进行微调，并使其在长期运行的情况下更加稳定
-
在单体架构时，因为服务不会经常和动态迁移，所有服务地址可以直接在配置文件中配置，所以也不会有服务发现的问题。但是对于微服务来说，应用的拆分，服务之间的解耦，和服务动态扩展带来的服务迁移，服务发现就成了微服务中的一个关键问题。 服务发现分为客户端服务发现和服务端服务发现两种，架构如下图所示。 这两种架构都各有利弊，我们拿客户端服务发现软件Eureka和服务端服务发现架构Kubernetes/SkyD