events - In Domain Driven Design - single public entity model, or model per bounded context?

Question

In Domain-Driven Design, we try to separate concerns between the functional areas (bounded contexts), and minimize dependencies between the contexts. The same entity can have different internal representation in different contexts. But in the communication between contexts (e.g. exposed APIs and/or events), do we tailor the representation of entities to each data consumer, or rather do we use a common representation?

For example, take the well-known separation (as diagrammed by Martin Fowler) between the Sales and Support contexts. Both contexts need to be aware of Customer and Product. But in Support context, a Customer has a list of Tickets; while in Sales context, a Customer is assigned to a Territory. Quite possibly, the internal representations will be completely different in the two contexts. But for exposed APIs and events, do we have a single Customer model that includes both these features, or do we have multiple models per context.

Answer 1

拥有单独的有界上下文的要点是可以自由地以适合该特定上下文的方式表达实体，而不必担心系统的其余部分。这就是您在有界上下文中主要管理功能清晰度和数据神圣性的方式。因此，在不同的上下文中以不同的方式代表 Customer绝对是有意义的。

您可以将单独的有界上下文视为不同的微服务。它们单独部署和扩展，不共享数据。它们的 API 是独立的，可以满足它们自己上下文的功能。他们拥有模型并负责在其边界内维护数据的神圣性，而无需担心应用程序的其余部分。

请注意，当您对相关概念有不同的模型时，您通常必须跨上下文保持相同的身份。您可以通过从初始化实体的第一个上下文发布域事件来实现此目的，以便其他上下文适当地填充自己。

在 Fowler 的示例中，销售上下文可能是初始化客户的第一个上下文。所以销售上下文会产生身份。然后，支持上下文通过侦听CustomerCreated域事件向自己添加一条记录，例如，预测来自客户的未来支持呼叫。

当您需要整理来自不同有界上下文的数据时，您通常会编写一个单独的查询或报告服务，该服务使用域逻辑之外的直接查询进行操作。获取数据并组织数据以进行演示的视图/查询通常位于域逻辑之外。