CQRS 第一个 NF 读取模型 - 您允许重复到什么程度？
我开始进行我的第一个真正的 CQRS 设置。我正在构建网站的用户注册部分，域和写入端对我来说非常熟悉，来自标准的 DDD“风格”。对于读取模型，我有一个处理 AccountCreatedEvent 的反规范化器。
目前 - 对于我正在实现的功能，我只对让用户注册感兴趣。这涉及检查电子邮件地址/用户名的唯一性。
所以，假设我专门为此目的设计了一个读取模型。一个 AccountRegistrationReadModel，它只保存我现在感兴趣的数据部分：用户名、电子邮件、HashedPassword
稍后，当我开始构建用户个人资料页面时，我将需要一个 AccountProfileReadModel。
该读取模型将共享一些相同的属性，并且将有另一个反规范化器来处理与更改配置文件数据相关的事件，例如 AccountUsernameChangedEvent
此时，AccountRegistrationReadModel 和 AccountProfileReadModel 有兴趣侦听 AccountUsernameChangedEvent 消息。
我的问题是：这种方法正确吗？我应该为每个功能保留一个读取模型吗？或者我应该尝试对其进行标准化并重新使用数据，尽可能限制重复？
I'm starting out with my first real CQRS setup. I'm building out the user registration part of the site, the domain and the write side are very familiar to me coming from a standard DDD "style". For the read model I have a denormalizer which handles the AccountCreatedEvent.
For now - for the feature I am implementing, I am only interested in getting users registered. That involves checking uniqueness of email address/username.
So, Say I design a read model specifically for this purpose. an AccountRegistrationReadModel which only holds the parts of the data I'm interested in right now: Username, Email, HashedPassword
Later on, when I start to build up the user profile page, I'm going to need an AccountProfileReadModel.
This read model will share some of the same properties and will have another denormalizer which handles events related to changing profile data, perhaps for instance AccountUsernameChangedEvent
At this point the AccountRegistrationReadModel and the AccountProfileReadModel are interested in listening to the AccountUsernameChangedEvent messages.
My question is: Is this approach correct? Should i be keeping a read model per feature? Or should I try to normalize it and re-use data, limit duplication where possible?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为像大多数设计问题一样，答案取决于你。共享将节省计算资源并限制随着时间的推移必须调试的位置数量。但共享也会将事物耦合在一起，这可能是不必要的，从而导致不同类型的成本：脆弱性。在具有数千个用户和无聊查询的系统中，数据库中的简单而经典的用户表可能适合大多数读取模型。如果您必须扩展到大量用户或大量消息，您可能会发现其他一些视图（审核日志？当前活动的发货？等）将涉及更有趣的非规范化或实现。
I think like most design questions, the answer is that it is up to you. Sharing will save computing resources and limit the number of places you have to debug over time. But sharing will also couple things together, potentially unnecessarily, resulting in a different type of cost: brittleness. In a system with a few thousand users and boring queries, a simple and classical user table in a database might do for most of your read models. If you have to scale to huge numbers of users, or a huge number of messages, you'll likely find that some of your other views (audit log? Currently active shipments? Etc) will involve more interesting denormalization or implementation.
我同意@Sebastian 在他的回答中所说的。我还想补充一点，在我看来，CQRS 模式为您提供了快速读取的能力，但代价是修改过程稍慢（由于标准化）。你的读数与相当平坦的数据相悖；因此，您的数据存储中会出现一些重复。但是你的反规范化器可以保持更新。
所以，正如@Sebastian 所说，这取决于你。但迁移到 CQRS 的主要好处是快速读取和可扩展性。如果您开始标准化数据并跨模型共享数据，那么您将回到更传统的 CRUD 应用程序。到那时，CQRS 确实无法帮助您——因此使用它可能没有多大意义。
希望这有帮助。祝你好运！
I agree with what @Sebastian said in his answer. I'd also add that, in my opinion, what the CQRS pattern gives you is the ability to have fast reads at the expense of a slightly slower modification process (because of normalization). Your reads go against pretty flat data; as a result, you have some duplication in your data store. But your denormalizers handle keeping that updated.
So, as @Sebastian said, it's up to you. But the key benefit of moving to CQRS is fast reads and scalability. If you start normalizing your data and sharing data across models, then you're moving back to a more traditional CRUD application. At that point, CQRS really isn't helping you -- so there may not be much of a point in using it.
Hope this helps. Good luck!