If this is a web system, put that information from the command in the cookie and then overlay it on the data retrieved from the query side. You can do similar things in smart clients.

In that way, it won’t show the old address when the user looks at it, irrespective of the fact that the query side is delayed.

Udi, you commented above that if your wife and you both change your account address, it’s okay for the system to apply both commands. I get that, but how do ensure that the data is not stale if you forgot to change something on your account moments later? If your change address command is not issued synchronously (or at least nearly immediately), you’ll see the old address (from cache) on your edit account view. Being a user, you’ll scowl and mumble something to the effect of, “I just changed my address! Why is it still showing my old address?”

What do we do in the cases of our users self-editing information in the system that they expect to see freshly updated?

I’ll try to provide a simple example: Suppose I have two ACs; one handling customer registration and another handling order submission. They both depend on one piece of information; whether the user’s country is part of the EU. In the registration case, we’d like to give the user a discount if he’s in the EU and in the orders case, the shipping costs will depend on that piece of information.

Definitely, the information about a country being in the EU is not contained within the registration or orders contexts. So the question is: Should those ACs request such information from another AC?

In essence, should ACs direct their data queries to other ACs?

Thanks

I’ve answered some of these questions as presented on the DDD discussion group.

On the issue of collections, line items in an order need not be accessible outside of the order. We can handle the customer’s total order value with a property on the customer entity that is updated on each order. This structure would more closely reflect the language of the domain too.

Hope that helps.

["And if we’ve already got a notification model set up, do we really need to return an error to the customer service rep? I mean, it’s not like they can do anything about it other than notifying the customer."]
IMO you’re making too many “if” assumptions in that deduction. Let’s branch the hypothetical a bit and take another real-world case where an attempt to place an order is invalidated because the combination of the selected handset/service/contract-type is not available. The sales rep will *need* to be notified “synchronously” about this, so he can try again with a different combination that are valid according to the business-rule (by talking it through with the customer of course). Order-submission is a command, and it *is* expected to give an immediate feedback to the sales rep upon its failure/success.
Another highly common example is to perform credit-check via an external institution before allowing the sales-rep to progress further into product selection screen, or perhaps limitting the product selection to certain amount of value, based on the customer’s credit-rating calculated by the legal institution. A request to perform a credit-check via a legal institution is a command, and again, an immediate feedback to sales-rep is expected.

["Do we really need a collection of orders on the customer entity? In what command would we need to navigate that collection?"]
In the commands where we might perform business-rule to apply certain logic if customer’s total orders have exceeded certain value. Probably doesnt make sense in this case since customer and order are probably 2 different aggregate roots. But more sensible in the case of order and order-items (e.g. “checking that all order-items within the order are within certain threshold”. Or, “if all the order-items within a single order are delivered to a maximum of 3 different addresses”).

If anybody (Udi? ) is stil following comments here, can someone elaborate a bit on how to keep the read site up to date?

Say I assign a user a new role, resulting in a UserAssignedNewRole event containing the UserId and RoleId. When i go to update my “UsersWithRoleName” read-side table, am i suppose to have the roles stored seperately on the read side, in order to find the role name, to put in?

This could potentialy mean storing the entire model as well as the denormalized tables on the read side.. ..would you recommend this or do you have an alternate approache?

Kind regards
Olav

Glad you liked it.

You don’t necessarily need to include the cache-updating AC if you implement your query store as views on top of your domain store. Keep in mind that this doesn’t mean you can skip thinking about the level of staleness that the business is willing to live with.

All in all, sounds good.

I’m considering simplifying one aspect of this pattern in my initial implementation. I’m using SQL Server for my main data store. Rather than creating a separate physical query store, I’m going to create a set of view-specific indexed views and stored procedures in the same database. I’ll use a separate SQL Server schema (named QueryStore, or something like that) and a separate connection string in my config files. This way I don’t need worry about synchronizing the query store – it’s done automatically. View indexes and object-level locking should help with performance, but if the day comes that I need to scale my query store out to its own database/server, I should be able to do so without major re-architecture of other components of the system.

If the data is needed by the client as soon as it is submitted, it is there – on the client that submitted it. No need to poll the query side. The only thing that might not have been there is an ID from the database – which is easily solved with client-generated GUIDs instead of database-generated IDs.

What would you do in that case?

I don’t think Comet is needed for that – some simple browser side javascript (aka AJAX) can take the data that was submitted in the command and append it to the results from the query side. As this is browser side, it brings no scalability overhead. Hope that answers your question.

How would you see integrating this with Comet, in order to make the result from the repo db appear in the same page where the command was requested? Does this scale? Is there any disadvantage of using this approach?

If we don’t have any other means to communicate with the user, like another email address (Yahoo does this), let’s say we did nothing. This is a rare occurrence – a race condition between two users for the same email.

What is likely to happen is that the user will try to login at some time in the future, won’t succeed, and will re-register (or give up).

In the case they give up, saving this one user in a million probably isn’t worth the cost of doing so. Even though I’m guessing that that’s an answer you don’t want to hear

you suggest before to only rely on exceptions in exceptional situations (like db not available), but is this the case here? as i said an unique const violation is normal behaviour (like email adr must be unique), isn’t it?

Then we would have a try catch for that specific type of exception in that handler

you suggest to let a db constraint check uniqueness as in comment #46. in case of a violation the db provider throws an exception. Typically exceptions causes msgs to get poisoned, which causes retries, which maybe succeed if the value becomes availible but ultimatly the msg will go to an error queue. but in case of a unique constaint violation there is hardly anything an admin can do with the msg in the error queue, rather its a “normal event”. also some component has to catch that and notify the user somehow.

my question is: how do you handle that?

Our goal is to identify along with our business stakeholders which user intent is significant. If your business logic has ‘if’ statements to do something about a given scenario, it is likely that we need to introduce a command for that. Typing more commands is the least of our worries.

It is likely the batch processing that you’re describing isn’t a command in its own right, rather it is a batch of commands, where each can succeed or fail independent of the others.

On the other hand, this can be an ETL-style thing, in which case the previous statement may not hold.

I’d deal with the above questions before looking at efficiency. If the former is the case, you can parallelize the execution of commands, even if it appears inefficient at first blush.

Hope that helps.

Great to read and finally understand the essence of CQRS. My only fear is that how do you deal with command explosion? for instance there maybe a hundred different reasons why somebody would change their name and having a command indicating the intent of each and every one seems a little silly.

I guess with most things a little common sense applies here correct?