我的团队正在开始实现一个绿地应用程序，需要 Multi-Tenancy 。我一直在对简单可扩展性的模式进行大量研究，特别是在基于云的分布式基础设施上，而 CQRS 似乎是当今的流行词(甚至被称为“架构迷的破解”，我觉得这很有趣) )。抛开好处和陷阱不谈，除了 Greg Young 之外，很难找到任何人在生产应用程序中广泛(或根本)使用了这个想法，并且可以为其提供现实世界的指导。
这是我的问题: 1. CQRS 架构是否适合您典型的 Multi-Tenancy 应用程序，或者它更适合更大规模的内部企业应用程序。 2. 如果您建议在这种情况下使用它，您能否提供一些关于方法的实际指导，特别是关于尽早做好的事情，以及哪些方面应该有机发展。 3. 如果有人尝试后发现太难或没有意识到好处，或者有强烈的反对意见(并建议坚持 CRUD 和分层设计)，我也想了解这些经验。
作为引用，该应用程序将用 .NET 编写，前端最初将基于 Web (ASP.NET MVC)，可能会扩展到移动客户端和胖客户端。并发性、交易事件和数据量预计在应用程序的整个生命周期中保持相对较低的水平(与大容量的金融应用程序等相比)。对于基础设施，我们计划使用 Azure。
最佳答案
- Multi-Tenancy 会稍微改变 CQRS 的读取方式。您将需要过滤 View 并仅返回与租户相关的数据。使用任何其他架构您都会面临同样的问题。
- 我会推荐 CQRS，因为它将使您的应用程序基于任务(而不是基于 CRUD)。这意味着您将从 UI 接收命令，并且它们比 DTO 更有意义。 如果您想用 DDD 原则编写核心，那么请尽量避免贫血域模型 ( http://martinfowler.com/bliki/AnemicDomainModel.html )。实现此目的的方法是将所有特定于域的逻辑移至域对象。您的命令处理程序应该非常简单(验证、加载聚合根、将命令对象转换为方法调用，如果没有抛出异常 - 应用更改)。 值得一看的是 Greg 的类记录(6 个半小时):http://cqrsinfo.com/video/ 正如 Michael Shimmins 所说，如果您计划使用 Azure 作为平台 - 值得关注 Lokad.CQRS 项目。我用它来实现我们的一个项目。
- 如果您确实需要简单的 CRUD 应用程序(不是基于任务的)，CQRS 将不适合。对于新手来说，CQRS 需要更多时间来理解它的原理。另一方面，它将允许将领域核心程序员和经验不足的 view->dto->ui 程序员之间的开发任务分开。
关于.net - Multi-Tenancy CQRS 架构，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4446140/