【发布时间】：2021-11-19 18:18:55
【问题描述】：
我们正在努力整合有界上下文和多语言文本。
作为更大系统的一部分，我们有一个定界上下文和一个仓库定界上下文。用户将来自特定仓库的产品放入购物车。某些产品可以在购买时或购买后进行定制（例如添加名称或选择服务执行日期）。因此，我们在订单上下文中使用采购实体，在仓库上下文中使用产品实体。采购实体持有处理订单所需的部分产品信息（如产品名称）、定制信息以及产品和仓库的ID。
产品信息以多种语言输入。为了显示购物车，仓库上下文提供了可购买的产品列表。订单期间可以选择更改语言。此外，不同国家/地区的法律要求可能不同，发票等文件可能需要以当地语言访问和存档。因此，订单和发票等文件应该可以用不同的语言创建/显示。
我们不确定如何处理采购实体中的多语言信息，因为这些信息来自仓库上下文。
选项1）只保存购买实体中的ProductId，每次需要时从仓库上下文中重新查询语言。
这将允许以以后添加的语言显示文档。在我看来，它会过多地结合上下文。我宁愿让订单上下文独立于报告和归档。更改 UI 中的显示语言时，需要更改 UI 和产品信息。由于 UI 特定文本是固定的，它通常由客户端通过资源文件（例如 Angular 作为前端）进行交换。产品信息是动态的，因此客户端需要从后端重新查询所有显示的数据。这意味着至少订购过一次的停产产品永远不能从仓库上下文中删除，因为显示订单需要数据。
选项 2) 将所有可用语言复制到采购实体中。
这将使订单上下文独立于报告和归档。如果产品信息也以所有支持的语言传递给客户端，则 UI 更改不需要对后端进行任何调用。使用几种语言并且没有太多产品信息，这可以很好地工作，但很可能会在使用多种语言时产生性能问题。此外，如果稍后添加一种语言，它将不会自动可用。
有两个不同的问题。一是UI语言变化。另一个是有界上下文之间的通信。如果客户端需要查询后端的 UI 更改，这不是一个大问题，因为它不是一个频繁的操作。我更担心的是，对于购物车的每个操作和显示选项 1，订单上下文需要访问仓库上下文，并且完全依赖于显示购物车或订单文档，即使没有任何变化。我主要关心的是归档和法律规则。如果已下订单，则数据必须保持不变。如果更新了订单，则可以添加或删除产品，但每个产品都是一个新的订单行。以前的数据必须保持不变。因此，向另一个不受控制的有界上下文询问必须保持不变的数据是不对的。对我来说唯一合乎逻辑的过程是在订单上下文中创建一个副本。
一种折衷的解决方案可能是仅复制下订单所用的语言，并最终将不同的法律语言复制到购买中，以满足对未更改数据和存档的要求。如果以后想要以不同的语言查看订单数据，可以查询仓库上下文。
有人遇到过这个问题吗？有界上下文之间以及上下文和 UI 之间的多语言文本交换的最佳实践吗？我们对有界上下文的思考是否存在问题？感谢您的帮助。
马库斯
【问题讨论】：
标签： domain-driven-design multilingual bounded-contexts