在领域驱动设计中，我们试图在功能区域(有界上下文(之间分离关注点，并最大限度地减少上下文之间的依赖关系。同一实体在不同的上下文中可以具有不同的内部表示。但是，在上下文之间的通信中(例如，公开的API和/或事件(，我们是根据每个数据消费者定制实体的表示，还是使用通用表示？
例如，以销售和支持上下文之间众所周知的分离(如Martin Fowler所示(为例。这两种情况都需要了解客户和产品。但在Support上下文中，客户有一个Tickets列表；而在Sales上下文中，Customer被分配到Territory。很可能，在这两种情况下，内部表征将完全不同。但是，对于公开的API和事件，我们是有一个包含这两个功能的单一客户模型，还是每个上下文有多个模型。
拥有单独的有界上下文的目的是可以自由地以适合特定上下文的方式表达实体，而不必担心系统的其他部分。这就是您在有限上下文中主要管理功能清晰性和数据神圣性的方式。因此，让客户在不同的上下文中以不同的方式表示是有意义的。
您可以将单独的有界上下文视为不同的微服务。它们是单独部署和扩展的，不共享数据。它们的API是独立的，以适应它们自己上下文的功能。他们拥有模型，并负责维护其边界内的数据神圣性，而不必担心应用程序的其他部分。
请注意，当一个相关概念有不同的模型时，通常必须在不同的上下文中保持相同的身份。您可以通过从初始化实体的第一个上下文中发布域事件来实现这一点，以便其他上下文适当地填充它们自己。
在Fowler的例子中，销售上下文可能是初始化客户的第一个上下文。因此，销售上下文将生成身份。然后，支持上下文通过侦听CustomerCreated域事件向自身添加一条记录，例如，预测客户将来的支持呼叫。
当您需要整理来自不同有界上下文的数据时，通常会编写一个单独的查询或报告服务，该服务使用域逻辑之外的直接查询进行操作。获取数据并组织数据以进行表示的视图/查询通常处于域逻辑之外。