DDD - 从另一个微服务保存数据
DDD - Save data from another microservice
我在一家拥有多家其他公司(每家都有自己的应用程序)的公司工作,我们开始集中一些数据,例如,现在我们有一项服务可以为每家公司共享客户数据,让我们将其命名为 CustomerService。
我正在工作的项目使用订阅模式,客户可以订阅健康保险计划并且只能拥有一个有效计划(我们称之为 HealthInsuranceService)。
我们必须显示客户在我们生态系统的某些应用程序中订阅了哪个计划,例如,我们有一个药店应用程序,我们必须在药店应用程序的客户资料中显示该客户拥有哪个计划。就 DDD 而言,哪个选项更好?
- 将planId保存在CustomerService中,这样每个应用程序都可以访问我们的planId。我在这里看到了一些缺点,例如,如果我们允许每个服务将其数据存储到 CustomerService 中,它将随着仅用于某些应用程序的数据而增长。 get Customer 端点将变得越来越大。
- 保存 planId 并在 HealthInsurance 中缓存一些客户数据,使用事件驱动。每个需要此信息的应用程序都必须从此服务调用端点以检索 planId。这里的缺点是获取planId会是另外一个请求。
- 在药店应用程序和需要此数据的每个应用程序中缓存 planId(通过事件驱动)。
- 使用将用于所有应用程序的 api 网关合并来自 customerService 的客户数据和来自 HealthInsuranceService 的计划数据。
我们还有更好的选择吗?
None 从严格的 DDD 角度来看,其中的
None 本质上比其他的更糟糕。选择哪一个取决于问题的重要性。
选项 3 可能是我倾向于选择的(基本上是 CQRS)是我为了确保服务自治而倾向于选择的,但这种自治需要更宽松的一致性保证(即改变保险计划可能不会立即显示在药店应用程序中)。另一方面,如果需要更强的一致性保证,则选项 3 几乎可以肯定是 4 个选项中最差的。
我在一家拥有多家其他公司(每家都有自己的应用程序)的公司工作,我们开始集中一些数据,例如,现在我们有一项服务可以为每家公司共享客户数据,让我们将其命名为 CustomerService。
我正在工作的项目使用订阅模式,客户可以订阅健康保险计划并且只能拥有一个有效计划(我们称之为 HealthInsuranceService)。
我们必须显示客户在我们生态系统的某些应用程序中订阅了哪个计划,例如,我们有一个药店应用程序,我们必须在药店应用程序的客户资料中显示该客户拥有哪个计划。就 DDD 而言,哪个选项更好?
- 将planId保存在CustomerService中,这样每个应用程序都可以访问我们的planId。我在这里看到了一些缺点,例如,如果我们允许每个服务将其数据存储到 CustomerService 中,它将随着仅用于某些应用程序的数据而增长。 get Customer 端点将变得越来越大。
- 保存 planId 并在 HealthInsurance 中缓存一些客户数据,使用事件驱动。每个需要此信息的应用程序都必须从此服务调用端点以检索 planId。这里的缺点是获取planId会是另外一个请求。
- 在药店应用程序和需要此数据的每个应用程序中缓存 planId(通过事件驱动)。
- 使用将用于所有应用程序的 api 网关合并来自 customerService 的客户数据和来自 HealthInsuranceService 的计划数据。
我们还有更好的选择吗?
None 从严格的 DDD 角度来看,其中的
None 本质上比其他的更糟糕。选择哪一个取决于问题的重要性。
选项 3 可能是我倾向于选择的(基本上是 CQRS)是我为了确保服务自治而倾向于选择的,但这种自治需要更宽松的一致性保证(即改变保险计划可能不会立即显示在药店应用程序中)。另一方面,如果需要更强的一致性保证,则选项 3 几乎可以肯定是 4 个选项中最差的。