领域驱动设计 - 跨界上下文共享实体

Question

我是领域驱动设计的新手，并尝试在我的项目中学习和实施。到目前为止，我的项目结构与此类似。

维护文件夹
  Maintainance.Data(Class 库）
  Maintainance.Domain（类库）
Maintenance.Domin.Tests(测试项目)

MovieBooking 文件夹
  MovieBooking.Data(Class 库）
  MovieBooking.Domain（类库）
MovieBooking.Domain.Tests(测试项目)

SharedKernel
  常见的东西

Web 应用程序
  MovieBooking MVC Web 应用程序（参考MovieBooking域）

在Maintainance 有界上下文中，我在Maintainance DBContext 中保留所有CRUD、GetAll 类型的东西，例如电影、国家、类别、子类别实体。 现在在MovieBooking 数据层中，我还需要使用这些实体（主要用于显示名称或下拉填充视图，需要一种子集 - 不需要所有属性，只有少数属性，如 Id、名称）

我可以通过几种方式在电影预订限界上下文中访问此实体

1. 通过网络服务 - 需要为电影、国家、类别、子类别等常见实体创建网络 API，并在网络项目中调用网络 API（以填充下拉菜单或从实体获取名称）

2. 通过引用上下文（单独的 Dbcontext） - 需要配置 Dbset，然后将数据库视图（仅需要字段）映射到 Dbset 示例：

   modelBuilder.Entity().ToTable(ViewName);

对于 (1)，它可以是我的长期实施解决方案
(2) 我必须为每个需要表创建视图（只有几个属性），并且由于我有企业级应用程序，它将大大增加我在数据库中的视图数量。

还有其他方法可以实现吗？我在 DDD 中缺少什么要查找的内容？

Answer 1

选项 2 虽然可以节省您的时间，但从 DDD 的角度来看实际上是一个非常糟糕的主意，因为它允许违反事务边界保证每个聚合都旨在执行\表示。

选项 1 似乎是一个更好的选择，尽管根据您对提议的解决方案的简要描述，仍有相当多的解释空间。如果我理解正确，一般建议遵循以下：

1. 不要直接暴露聚合状态，因为这会暴露内部结构并增加耦合。简单地创建有意义的 DTO 并使用 Automapper 之类的东西将您的聚合轻松映射到 DTO，然后再发送。
2. 在您的客户端中有一个 DTO 定义的副本。这将减少耦合并简化部署。

我强烈建议阅读 DDD orange book，尽管我不得不说我记不起具体讨论的是哪一章。通过阅读有关六边形架构的信息，您还将受益匪浅（我会在橙皮书中搜索该术语以找到有关您问题的更多信息）。

实际上我可以想到一个替代方案：如果您要从 BC 发布事件，您可以创建一个工作流来将域事件转换为“公共”事件，然后在另一个 BC 中监听公共事件您需要将所需的数据存储在里面的某个地方。这取决于您的基础设施，其难度从非常容易到非常有问题。请注意，重复使用您的域事件将数据传输到其他 BC 并不是一个好主意，因为这将两个 BC 紧密耦合。

我希望这会有所帮助。如果我没有充分理解这个问题，请不要犹豫，详细说明。