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 回答