Asp.net mvc 是否有可能在整块应用中正确使用DDD和所有构建块？

我看了一些视频，读了一些博客。关于这个问题有很多问题和答案，但我找不到确切的答案

几乎每个问题和答案都缺乏使用上下文

我有一个中型的asp.net-mvc，monolith应用程序，它在IIS上的一个进程中运行。我想（重构并）一直使用DDD（和CQR，目前没有单独的读写存储），但对我来说，如果不打破一些规则/指南/等等，这看起来是不可能完成的任务

有界上下文 例如，我有多个BC。每个人都不应跨越其边界，这意味着不应共享其存储。对吧?

如果您使用整个已知的（分散在web上的任何地方）解决方案来处理NHibernate会话和UoW，这是不可能的

聚合根 在一个事务中只能修改一个应收账款。当涉及到其他人时，ARs应该引入最终的一致性（如果我记得这些是Eric Evans的话）

我试着去做，但在这样的应用程序中并不容易。发布/订阅未按预期工作，因为如果事件已发布，则所有订阅服务器都将在一个事务中执行操作（NSB/MT就是这样做的）

如果事件处理程序想要修改其他ARs，它们应该在单独的事务中执行，对吗

是否可以在monolith应用程序（整个代码在一个进程中工作的应用程序）中处理它

如果你使用整个已知的（分散的）数据是不可能的 通过网络）解决方案

[……]

如果事件已发布，则所有订阅服务器都将执行其操作 一笔交易内

我认为你试图坚持一些“最先进的技术”是在给自己设置无用和有害的限制

将整个应用程序迁移到DDD+CQRS是一项艰巨的任务。它的一些领域还没有很好的记录，你可能会有一些探索要做。我最好的建议是与“人们做事的方式”保持合理的距离。在传统ASP.Net web应用程序中，因为主流实践通常与DDD+CQR的工作方式不匹配；在CQR中，因为案例研究很少，而且很可能非常特定于领域，倾向于提倡使用在您的环境中可能没有意义的重型工具

你可能需要跳出思维定势，循序渐进地接受事物，并避免把一切都镀上金色。与在代码库中投入大量工具和框架相比，最好从非常简单的、完全符合您需求的实现开始

例如，您真的需要一个服务总线，还是一个简单的观察者模式就足够了

---

关于NHibernate，大多数实现都使用（单个）每个请求会话的方法，但仅仅因为它最流行并不意味着它是唯一的方法。您是否尝试过在更可编程的级别使用多个iSession（每个BC一个），例如每个操作，或者完全手动管理？相反，您是否考虑过首先在有边界的上下文之间共享数据库，然后自己看看这是否糟糕？

我会说这是可能的。但是，如果你想用同样的性能达到同样的效果，那是不可能的。我不确定你对所有事件处理程序的一个事务是否正确。NServiceBus具有UoW管理器的概念，它在每次处理程序调用时开始和结束。@AlexeyZimarev如果从事务队列中拾取消息会怎么样？TransactionScope必须包含所有处理程序，即使每个处理程序都有自己的UoW。