多租户CQRS架构

Question

我的团队正在开始实施绿地应用程序，需要多租户。我一直在进行大量关于简单可扩展性模式的研究，特别是在基于分布式云的基础架构上，而且CQRS似乎是热门话题（就像被称为“Crack for Architecture Addicts”一样，我觉得很有趣）。除了好处和陷阱之外，很难找到除Greg Young之外的任何人在生产应用程序中广泛（或根本）使用这个想法并且可以为它提供真实世界的指导。

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

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

Answer 1

1. 多租户将改变一点CQRS读取方。您将需要过滤视图并仅返回与租户相关的数据。使用任何其他架构，您将面临同样的问题。
2. 我会推荐CQRS，因为它会使您的应用程序基于任务（不是基于CRUD）。这意味着您将从UI接收命令，它们将比DTO更有意义。 如果您想用DDD原则编写核心，请尝试避免遗忘域模型（http://martinfowler.com/bliki/AnemicDomainModel.html）。执行此操作的方法 - 将所有特定于域的逻辑移动到域对象。您的命令处理程序应该非常简单（验证，加载聚合根，将命令对象转换为方法调用，如果没有抛出异常 - 应用更改）。 值得观看格雷格的班级记录（6个半小时）：http://cqrsinfo.com/video/ 正如Michael Shimmins所说，如果您计划使用Azure作为您的平台 - 那么值得关注Lokad.CQRS项目。我用它来实现我们的一个项目。
3. 如果您真的需要简单的CRUD应用程序（不是基于任务），CQRS将不适合。 CQRS需要更多时间来了解新手的原则。另一方面，它允许在域核心程序员和经验较少的视图 - ＆gt; dto-＆gt; ui程序员之间分离开发任务。

Answer 2

在开始实际项目（我们仍在等待商业资金）之前，我已经从探索性的角度审视了同一个起点。在那里，我的研究和意见是，该架构的多租户轴在很大程度上与使用CQRS进行粗粒度服务的内部设计正交。多租户要求对应用程序如何将租户与安全性，数据，演示/个性化，部署/供应和可扩展性视角进行隔离放置了额外的总体限制。 CQRS并没有真正使这更好或更糟，我认为仍然有价值解决服务的宝贵架构挑战。也就是说，并非所有松散协作提供应用程序的服务都需要遵循CQRS模式，前提是所选择的松散耦合架构不会禁止其使用。

Answer 3

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