我观看了一些视频，阅读了一些关于它的博客。 SO在这个问题上有很多问题和答案，但我找不到任何问题的确切答案。
几乎每个问题和答案都缺乏使用背景。
我有一个中等大小的asp.net-mvc， monolith 应用程序，它在IIS上的一个进程中运行。我想（重构和）一直使用DDD（和CQRS没有分开的存储空间用于读取和写入）但对我而言，如果没有破坏某些规则/指南等，它看起来就像是不可能的任务。
有界上下文 例如，我有多个BC。每个都不应越过它们的边界，这意味着不应该共享它们的存储。正确？
如果您使用整个已知的（Web上分散的）解决方案来使用NHibernate会话和UoW，则无法实现。
聚合根 在一次交易中只应修改一个AR。当涉及其他AR时，应该引入最终的一致性（如果我记得那些是Eric Evans的话）。
我尝试这样做，但在这样的应用程序中并不容易。 Pub / Sub没有按预期工作，因为如果事件发布，则所有订阅者都在一个事务中执行操作（NSB / MT就是这样）。
如果事件处理程序想要修改其他AR，则应该在单独的事务中执行，对吧？
是否可以在整体应用程序中处理它（整个代码在一个进程中工作的应用程序）？
答案 0 :(得分：1)
如果你使用整个已知的（到处散落的话）是不可能的 通过网络）解决方案
[...]
如果发布了事件，那么所有订阅者都会采取行动 在一次交易中
我认为你通过坚持一些“最先进的”来设置自己无用和有害的约束。
将整个应用程序迁移到DDD + CQRS是一项艰巨的任务。它的某些领域尚未有详细记录，但您可能需要进行一些探索。我最好的建议是与“人们做事的方式”保持合理的距离。在传统的ASP.Net网络应用程序中，因为主流实践通常与DDD + CQRS的工作方式不匹配，而在CQRS本身也是如此，因为案例研究的内容很少，而且很可能是特定于域的，并且倾向于提倡在您的环境中使用可能没有意义的重型工具。
你可能需要开箱即用，逐步采用事物并避免对所有东西进行镀金。除了在代码库中投入大量工具和框架之外，您最好从非常简单的实现开始，完全符合您的需求。
例如，您真的需要一个服务总线，还是一个简单的Observer模式就足够了？
关于NHibernate，大多数实现使用（单个）Session Per Request方法，但仅仅因为它最受欢迎并不意味着它是唯一的。您是否尝试过更多可编程级别的多个ISession（每个BC一个），例如按操作，或者完全手动管理？相反，您是否考虑过首次在有界上下文之间共享数据库，如果这是坏事，请自行查看？