cqrs

As I understand CQRS advocates separating read models from domain models and having a particular read model for every necessary domain model projection. From usage point, how the read model is stored and retrieved should be transparent - you issue a query and get a read model without caring about how it is made. Many examples and articles use separate tables for storing read models and re-generating them by response to domain model changes. I do not really like this approach because of the following reasons: Not all possible read models will be needed often; Requirement changes might

Supposed I have a CQRS-based system and my domain needs some data from an external web service to make its decisions. How do I model this correctly? I can think of two options: The command handler runs the domain logic and the domain itself calls out to the web service. Once it gets a response, it attaches the appropriate events to the current aggregate and stores them. The domain basically "waits" for the web service to return. The command handler runs the domain logic and the domain immediately emits a domain-internal more data needed event. A process manager reacts on this, talks to the web

In my CQRS architecture, I'd like to validate that when I send a InsertSettingCommand (setting is a key/value object), I want to check that the key doesn't already exist in my database. If I understand CQRS & validation well, it says that the validation should be performed in client side only when it's about verifying some formatting stuffs like checking that email respects some syntax or that customer's name is not empty. But in my case, I need to query my database to see if it exists, but I don't know if it's correct to query my read store in client-side ? Or should I call my read store in

I'm in the process of writing my first CQRS application, let's say my system dispatches the following commands: CreateContingent (Id, Name) CreateTeam (Id, Name) AssignTeamToContingent (TeamId, ContingentId) CreateParticipant (Id, Name) AssignParticipantToTeam (ParticipantId, TeamId) Currently, these result in identical events, just worded in the past tense (ContingentCreated, TeamCreated, etc) but they contain the same properties. (I'm not so sure that is correct and is one of my questions) My issue lies with the read models. I have a Contingents read model, that subscribes to

Example: Business rules states that the customer should get a confirmation message (email or similar) when an order has been placed. Lets say that a NewOrderRegisteredEvent is dispatched from the domain and is picked up by an event listener that sends of the confirmation message. When that is done some other event handler throws an exception or something else goes wrong and the unit of work is rolled back. We've now sent the user a confirmation message for something that was rolled back. What is the "cqrs" way of solving problems like this where you want to do something after a unit of work

Background : Diagrams explaining CQRS usually will have clear separation of read and write paths and one-way data flow, like in this example (source : Demystified CQRS ) : Question : I would like to clarify, If a Command execution in back-end requires some data from the database, should a "write side" have some read capabilities from write database? or it should completely rely on "read side" for any reads? or perhaps command should contain all the required data supplied by caller to be fulfilled? should a "write side" have some read capabilities from write database? Probably -- the most

Suppose you've got two aggregates in your bounded context which have some constraints amongst each other. Using DDD these inter aggregate constraints can't be enforced in the same transaction i.e. the aggregate boundaries are transactional boundaries. Would you consider using what in the Microsoft CQRS journey is called a "process manager" to coordinate two aggregates in the same bounded context or is a process manager only used to coordinate between two bounded contexts? What would the equivalent of a process manager that coordinates two or more aggregate roots within the same bounded context