正确的微服务域边界

Question

现在，我正在研究一个有趣的（至少从我的角度来看）业务案例，我必须在云环境中进行适当的设计。

假设我们有一个产品服务来处理所有产品目录数据，例如产品层次结构，产品描述和产品关系。该服务具有REST API，并提供了与产品配合使用的所有必要API，包括过滤，排序和搜索。

现在，我们又增加了一项服务：产品价格服务。该服务处理所有与定价相关的逻辑和计算，包括折扣，客户特定的价格。该服务还具有一个REST API，该API为所请求的一种或多种产品提供价格。

这时，情况似乎很简单：我们有2个职责明确的服务。从客户端的角度来看，一切看起来都很简单：

1. 请求产品
2. 要求产品价格

现在，我们有一项业务需求，要添加一个新的过滤器“低于20美元”。基本上，这意味着我们需要一个完全相反的工作流程：我们需要首先致电产品价格服务。此外，我们在产品服务中提供了一堆过滤器，可以轻松地与新的定价过滤器结合使用。

业务需求使我想到了这些服务的域边界，唯一的想法是边界是错误的（即使一开始就可以）。请分享您在这种情况下如何正确定义服务体系结构的经验/看法。

最好的问候， 阿图尔。

Answer 1

一种可能的（我认为是相当主流的）方法：API Gateway实现了API Composition pattern。在您的情况下，这意味着API网关执行以下步骤：

1. 为过滤后的页面（例如前20个）“低于20美元”的产品列表询问产品价格微服务。
2. 询问Products微服务以获取这20种产品的详细信息。
3. 将详细的产品列表返回给呼叫者Web前端。

这可以解决您的问题吗？

Answer 2

这是一个非常简单的折衷方案，您可以使产品服务了解客户价格，或者使过滤器忽略折扣，而仅按标价进行。大多数商店是这样过滤的，他们没有考虑个性化定价。

如果必须使用个性化定价，则需要进行经典的时间/空间权衡。您可以使用更多的空间但更少的时间将所有产品预先解析为价格，或者可以基于折扣即时计算价格，并且花费更多时间。

您可以通过将计算推到离数据存储更近的位置来最大程度地减少时间，而以节省架构成本为代价。打破体系结构纯度以达到性能目标是很常见的，这只是您需要明确做出的决定。

Answer 3

查找正确的域边界主要是为了找到最小的事务边界来设计集合。事务处理写端（想想CQRS）。对于阅读方面，您可以将其有用的任何方式进行混合和匹配。可以将其实现为单独的组件：产品搜索服务。例如，它可以使用ElasticSearch。

如果您的背景是在拥有许多部门和文档流的大型成熟组织中工作，则可以将组织结构视为良好域边界的示例，并从中获得启发。而且，如果外部实体从此类组织获得任何输出，则准备输出可能是某些专门部门的职责。

专门谈论您的问题，似乎客户级别或个人条件应该由某些CRM管理。这与价格服务分开。而且，在给定产品和基本价格的情况下，CRM应该确定要应用的折扣或价格列。

Answer 4

我认为您缺少有关DDD的非常重要的一点。简化DDD定义，它描述了用户发送命令时如何更改数据（应用程序状态）。它没有提供有关用户要问什么时该怎么做的指导。这当然是非常高级的视图。

要回答用户提出的问题，可以使用在合理的时间内提供准确答案所必需的任何方法。

因此，只要您不修改系统状态，就可以违反任何边界，读取任何私有状态或直接访问数据库以计算答案。

例如，某些架构模式（例如CQRS）完全基于此假设。

DDD中的边界（再次从高级角度出发）是有关如何设计软件的编写部分的指南。