CQRS 1st NF Read Model - to what extreme do you allow duplication?

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 s开发者_Go百科ome 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?

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.

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!