11

我的团队正在开始实施一个新的应用程序，需要多租户。我一直在对简单可扩展性的模式进行大量研究，特别是在基于分布式云的基础架构上，CQRS 似乎是当前的流行语（甚至被称为“Crack for Architecture Addicts”，我觉得这很有趣）。撇开好处和缺陷不谈，除了 Greg Young 之外，很难找到任何人在生产应用程序中广泛（或完全）使用了这个想法，并且可以为它提供现实世界的指导。

所以这是我的问题： 1. CQRS 架构是否适合您的典型多租户应用程序，还是更适合更大规模的内部企业应用程序。2. 如果你建议在这种情况下使用它，你能否提供一些关于方法的从头到尾的指导 - 特别是关于早期正确的事情，以及应该有机地发展哪些方面。3. 如果有人尝试过并且发现它太难或没有意识到它的好处，或者有强烈的反对意见（并建议坚持 CRUD 和分层设计），我也想知道这些经验。

作为参考，该应用程序将使用 .NET 编写，前端最初将基于 Web (ASP.NET MVC)，可能会扩展到移动和胖客户端。预计并发性、交易活动和数据量在应用程序的整个生命周期内都将保持相对较低（与大容量金融应用程序等相比）。对于基础架构，我们计划使用 Azure。

4

3 回答 3

8
  1. 多租户会改变一点 CQRS 读取端。您只需要过滤视图并返回与租户相关的数据。使用任何其他架构，您将面临同样的问题。
  2. 我会推荐 CQRS，因为它会使您的应用程序基于任务（而不是基于 CRUD）。这意味着您将收到来自 UI 的命令，它们将比 DTO 更有意义。如果你想用 DDD 原则编写你的核心，那么尽量避免贫血域模型 ( http://martinfowler.com/bliki/AnemicDomainModel.html )。执行此操作的方法 - 将所有特定于域的逻辑移动到域对象。您的命令处理程序应该非常简单（验证、加载聚合根、将命令对象转换为方法调用，如果没有引发异常 - 应用更改）。Greg的课堂记录（6小时半）值得一看：http ://cqrsinfo.com/video/ 正如 Michael Shimmins 所说，如果您打算使用 Azure 作为您的平台 - 值得一看 Lokad.CQRS 项目。我用它来实现我们的一个项目。
  3. 如果您真的需要简单的 CRUD 应用程序（不是基于任务的），CQRS 将不适合。CQRS 需要更多时间来了解它对新手的原则。另一方面，它将允许在域核心程序员和经验较少的 view->dto->ui 程序员之间分离开发任务。
于 2010-12-25T07:51:44.933 回答
6

在开始实际项目之前，我自己从探索的角度检查了相同的起点（我们仍在等待商业资金）。在那方面，我的研究和由此形成的观点是，架构的多租户轴在很大程度上与使用 CQRS 进行粗粒度服务的内部设计是正交的。多租户要求围绕应用程序如何将租户与安全性、数据、演示/个性化、部署/供应和可扩展性观点隔离开来设置额外的总体约束。CQRS 并没有真正使这变得更好或更糟，在我看来，在解决服务的有价值的架构挑战方面仍然具有价值。也就是说，并非所有松散协作以提供应用程序的服务都需要遵循 CQRS 模式，

于 2011-03-09T14:17:02.540 回答
2

我不认为多租​​户使用 CQRS 更难/更容易。如果使用消息传递，您将有多种优势：您可以将租户标识作为标头数据嵌入命令和事件中，根据标识选择事件存储，将多租户与多实例相结合。不过，问问自己您的领域是否高度协作，是否有领域专家可供您使用......否则您最终会得到命令/事件 cud ;-)

于 2010-12-15T10:23:08.273 回答