多租户 CQRS 架构
我的团队正在开始实施一个绿地应用程序，需要多租户。我一直在对简单可扩展性的模式进行大量研究，特别是在基于云的分布式基础设施上，而 CQRS 似乎是当今的流行词（甚至被称为“架构迷的破解”，我觉得这很有趣） ）。抛开好处和陷阱不谈，除了 Greg Young 之外，很难找到任何人在生产应用程序中广泛（或根本）使用了这个想法，并且可以为其提供现实世界的指导。
这是我的问题： 1. CQRS 架构是否适合您典型的多租户应用程序，或者它更适合更大规模的内部企业应用程序。 2. 如果您建议在这种情况下使用它，您能否提供一些关于方法的实际指导，特别是关于尽早做好的事情，以及哪些方面应该有机发展。 3. 如果有人尝试过，发现太难或没有意识到好处，或者有强烈的反对意见（并建议坚持 CRUD 和分层设计），我也想了解这些经验。
作为参考，该应用程序将使用 .NET 编写，前端最初将基于 Web (ASP.NET MVC)，并有可能扩展到移动客户端和胖客户端。预计并发性、交易活动和数据量在应用程序的整个生命周期中都将保持相对较低的水平（与大容量的金融应用程序等相比）。对于基础设施，我们计划使用 Azure。
My team is beginning implementation of a greenfield application, with a requirement for multi-tenancy. I have been doing a large amount of research on patterns for simple scalability, especially on distributed cloud-based infrastructure, and CQRS seems to be the buzzword du jour (going so far as being called "Crack for Architecture Addicts" which I find quite funny). Benefits and pitfalls aside, it is quite hard to find anyone besides Greg Young that has used this idea extensively (or at all) in production apps and can provide real-world guidance for it.
So here are my questions:
1. Does a CQRS architecture accommodate your typical multi-tenant application, or is it better suited for larger scale internal enterprise applications.
2. If you recommend that it is used in this situation, can you provide some from-the-trenches guidance on approaches - especially on things to get right early on, and what aspects should be evolved organically.
3. If anyone has tried and found it too difficult or not realized the benefits, or has strong arguments against it (and recommend sticking to CRUD and tiered design), I would like to know about those experiences as well.
For reference, the application will be written in .NET, and the front end will initially be web based (ASP.NET MVC), potentially being extended to mobile and thick clients. Concurrency, transactional activity, and data volume are all expected to remain relatively low throughout the lifespan of the application (compared to high volume financial apps and the like). For infrastructure, we plan on using Azure.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您想用 DDD 原则编写核心，请尽量避免贫血域模型 ( http://martinfowler.com /bliki/AnemicDomainModel.html ）。实现此目的的方法是将所有特定于域的逻辑移至域对象。您的命令处理程序应该非常简单（验证、加载聚合根、将命令对象转换为方法调用，如果没有抛出异常 - 应用更改）。
值得一看 Greg 的课堂记录（6 个半小时）：http://cqrsinfo.com/video/
正如 Michael Shimmins 所说，如果您计划使用 Azure 作为平台 - 值得关注 Lokad.CQRS 项目。我用它来实现我们的一个项目。
If you want to write your core with DDD principles then try to avoid Anemic Domain Model ( http://martinfowler.com/bliki/AnemicDomainModel.html ). Approach to do this - move all domain-specific logic to domain objects. Your command handlers should be very simple (authenticate, load aggregate root, translate command object to method call, if no exceptions were thrown - apply changes).
It's worth to watch Greg's class record (6 hours and a half): http://cqrsinfo.com/video/
As Michael Shimmins said if you plan to use Azure as your platform - it's worth to look at Lokad.CQRS project. I used it to implement one of our projects.
在开始实际项目之前，我自己从探索性的角度审视了同样的起点（我们仍在等待商业资金）。其中，我的研究和由此形成的观点是，该架构的多租户轴在很大程度上与使用 CQRS 进行粗粒度服务的内部设计正交。多租户需求围绕应用程序如何从安全、数据、表示/个性化、部署/供应和可扩展性的角度隔离租户施加了额外的总体约束。 CQRS 并没有真正让这一点变得更好或更糟，在我看来，CQRS 在解决服务的有价值的架构挑战方面仍然具有价值。也就是说，并非所有松散协作提供应用程序的服务都需要遵循 CQRS 模式，前提是所选择的松散耦合架构不禁止其使用。
I have examined the same starting point myself, from an exploratory perspective before embarking on the actual project (we are still awaiting the business funding). In that, my research and opinion formed therefrom is that the multi-tenant axis of the architecture is largely orthogonal to the use of CQRS for the internal design of a coarse grained service. The multi-tenant requirement places additional overarching constraints around how the application segregates the tenants from a security, data, presentation/personalization, deployment/provisioning and scalability viewpoint. CQRS does not really make this better or worse and in my opinion still has value in addressing valuable architectural challenges for the Services. That said, not all Services that loosely collaborate to provide the application need to follow the CQRS pattern either, provided that the loosely coupled architecture chosen does not prohibit its use.
我不认为使用 CQRS 来实现多租户更困难/更容易。如果使用消息传递，您将拥有多种优势：您可以将租户标识作为标头数据嵌入到命令和事件中，根据标识选择事件存储，将多租户与多实例相结合。不过，问问自己，您的领域是否具有高度协作性，并且有领域专家可供您使用……否则您最终会得到命令/事件 cud ;-)
I don't think multi-tenant is any harder/easier using CQRS. You have various advantages if you use messaging: you can embed tenant identification in commands and events as header data, select an eventstore based on the identification, combine multi-tenant with multi-instance. Still, ask yourself if your domain is highly collaborative and have a domain expert at your disposal ... otherwise you end up with command/event-cud ;-)