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

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

维护文件夹
维护数据（类 库）
维护.域（类库）
维护领域测试（测试项目）

MovieBooking文件夹
MovieBooking.Data（类 图书馆）
MovieBooking.Domain（类库）
MovieBooking.Domain.Tests（测试项目）

SharedKernel
普通事物

Web应用程序
电影预订MVC Web 应用程序（参考电影预订域）

在

maintenance

bounded上下文中，我在

maintenance

DBContext中保留所有CRUD、GetAll类型的内容，例如电影、国家、类别、子类别实体。 现在，在

MovieBooking

数据层中，我还需要使用这些实体（主要用于在视图中显示名称或下拉填充，需要的子集类型-不需要所有属性，只需要像Id、name这样的少数属性）

在电影预订环境中，我几乎没有办法访问这些实体

通过web服务-需要为常见实体（如电影、国家、类别、子类别）创建web api，并在web项目中调用web api（以填充下拉列表或从实体获取名称）

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

modelBuilder.Entity（）.ToTable（视图名称）

对于（1）它可以是我的长期实施解决方案
（2） 我必须为每个require表创建视图（只有很少的属性），这将大大增加数据库中的视图数量，因为我有企业级应用程序

---

我还有别的方法可以做到这一点吗？我在DDD中缺少什么可以寻找的

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

选项1似乎是一个更好的选项，尽管根据您对建议解决方案的简要描述，仍有相当大的解释余地。如果我理解正确，一般建议如下：

不要直接暴露聚合状态，因为这会暴露内部并增加耦合。简单地创建有意义的DTO，并在发送之前使用类似于将聚合映射到DTO的东西，这样做很容易，而且不费吹灰之力

在客户端中具有DTO定义的副本。这将减少耦合并允许更轻松的部署

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

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

---

我希望这有帮助。如果我对这个问题理解得不够透彻，请不要犹豫。谢谢您的回复。我打算看看你建议的那本书（橙色）。对于第（2）点——配置数据库集，然后将一个数据库视图（仅包含require字段）映射到数据库集，我已经参考了本文中的参考资料以及pluralsight中的课程：企业中的实体框架这是否与您对选项2的看法相关？如果我们不在同一条道路上，请提出建议。我觉得我有点迷路了，在黑暗中寻找光明：）也许这本书对我来说是一道亮光！！！重点是业务逻辑的隔离，您参考的文章实际上讨论了将大型dbcontext拆分为小型独立的dbcontext，这与我上面的建议完全一致。共享表允许一个BC更改另一个BC的状态，这实际上违反了从另一个BC的聚合中保证事务一致性的可能性。为了进一步解释，您可以共享db（但不是db上下文），并在每个BC中具有单独的db上下文，不同BC中的db上下文将无法访问相同的表。顺便说一句，如果你不做事件源，这是非常好的，但是我发现如果可能的话，最好也隔离db，这有助于独立部署每个服务而不影响其他服务。