Architectural issue

Question

As a result of a previous post ( Architecture: Simple CQS ) I was thinking how I can build a simple system flexible enough to be expanded later,

In other words: I don't see the need for a full-blown CQRS now, but I want it to be easy to evolve to it later if necessary.

So, I thought to separate the command from the queries, but both were based on the same database.

Part of the query will be simple: a view-based WCF data service that is easy to query for data. Nothing special.

The component of the command is something more complex, and here is the idea: the commands, of course, are executed asynchronously, so they do not return a result. But my ASP.NET MVC site controllers often need feedback from the team (for example, if the member registration was successful or not). Therefore, if the controller sends a command, it also generates a transaction identifier (guid), which is transmitted along with the properties of the command. The command service receives this command, places it in the transaction table in the database with the "processing" state, and executes (using DDD principles). After execution, the transaction table is updated, so the state becomes “completed” or “failed” and other more detailed information, such as the primary key that was generated.

Meanwhile, the site uses the QueryService to poll the status of the transaction until it gets “completed” or “failed,” and then it can continue its work based on this result. If the transaction table is polled and the result was “completed” or “failed”, the record is deleted.

A side effect is that I don't need guid as keys for my objects, which is good for performance and size.

In most cases, this polling mechanism is probably not needed, but is possible if necessary. And the interfaces are designed with CQS in mind, so they are open to the future.

Do you find any flaws in this approach? Any other ideas or suggestions?

Thanks!

People

Answer 1

I think you are very close to a complete CQRS system with your approach.

I have a website that I used to do something similar to what you are describing. My site braincredits.com is archived using CQRS, and all teams are asynchronous. Thus, when I create a record, the user has no feedback, except that the command was sent successfully for processing (and not processed).

But I have a user account on the site (the number of their "credits"), which should change as the user sends more items. But I do not want the user to continue to delete F5 in order to update the browser. So I do what you offer - I have an AJAX call that fires every second or two to see if the user’s account has changed. If so, the new amount is returned and the user interface is updated (with a little animation to get the user's attention, but not too flashy).

What you are talking about is the final sequence - the state of the application that the user sees will ultimately correspond to system data (recording system). This concept is quite important for CQRS and, in my opinion, makes a lot of sense. Once you retrieve data in the system (regardless of whether it is one of them based on CQRS), the data is old. But if you assume that you assume that the client will ultimately be consistent, then your approach makes sense, and you can also create your own user interface to account for this and take advantage of this.

As for the suggestions, I would look at how many surveys you do and how much data you send and back. Come overboard with a survey that sounds like you're not doing it. But set up what should be regularly updated on your site, and I think you will be good.

The WCF Data Service level for the query side is a good idea - just make sure it is turned on with read only (which I am sure you did).

Also, it looks like you got a great start.

Hope this helps. Good luck