CQRS or App Service?

Question

Therefore, I like the CQRS concept in our application, mainly because we already support event sources (conceptually, not following any prescriptions that you see there). However, it actually seems that CQRS is geared toward big data, ultimately towards consistency. We will always use the Relational DB application, so I'm not sure if it works.

I also have problems because I think I need to do something special at my application level. When reading, I need to provide security and data filtering, which are traditionally implemented at the application level.

My first question is: is my application suitable (traditional MVC / Relational DB application)? Or does it make sense to have a traditional application layer and use DTO Mapper?

My second question is: does it make sense to issue commands to your domain model from the traditional application level? I like the idea of ​​command / handler commands and eventing.

Let me clarify my question. I have problems around filtering data associated with authorization. When a user requests data, there should be a filter that restricts access to certain data elements, deleting them all together (so that they do not return to the caller), hiding values ​​or applying masks to the data. In a far-fetched example for a social security number, the user performing the request can see only the last 4 numbers, so the result will look like this: ### - ## - 1234.

My statement is that this responsibility lies at the application level. I consider this aspect when all responses to requests or commands must go through this filtering mechanism. That's where my CQRS naivety shines, maybe it's that the teams never return data, just pointers to the data that is viewed through the read model?

Thanks!

Answer 1

First of all: CQRS and Relational databases are not mutually exclusive. In advanced scenarios, it might make sense to replace the SQL database with other storage tools, but CQRS as a concept does not care about the storage mechanism.

In the case of several views, which depend on roles and / or users, a Thin level of reading should probably provide several sets of results:

• One containing the full SSN for users who are allowed access to this information.
• Other for users who are not allowed to see this information.
• ...

They can be stored in a separate data warehouse, but they can also be provided through SQL views if you are working with the same SQL database.

In CQRS, the Application Service still exists as Command Handlers . They can be nested, that is, first process authorization, and then send a command to the contained command handler.

public class AuthorizationHandler { public CrmAuthorizationService(CrmCommandHandler handler) { _next = handler; } public void Handle(SomeCommand c) { if (authorized) _next.Handle(c); } } // Usage: var handler = new CrmAuthorizationService(new CrmCommandHandler()); bus.Register<SomeCommand>(handler.Handle); 

This way you can nest several handlers, for example. like a REST envelope, for logging, transactions, etc.

To answer your questions:

First: Is CQRS suitable for your application? No one can say without delving into specific requirements. Just because you use MVC and a relational database doesn't mean anything when it comes to the pros and cons of CQRS.

Second one . Yes, in some cases it may make sense to allow your application layer to interact with the client in a classic way and handle things like authentication, authorization, etc., and then issue commands inside. This can be useful when placing a MVC-based user interface or REST API on top of your application.

Update in response to comment:

In an ideal, purist CQRS scenario, Sally would have her own denormalized data for each species, for example. multiple documents in a NoSQL database called CustomerListForSally, CustomerDetailsForSally, etc. They are filled with what she is allowed to see.

As soon as she receives a promotion - which will be an important event in the domain - all her denormalized data will be automatically overwritten and expanded to contain what she allowed to see now.

Of course, we must remain rational and pragmatic, but this ideal should be the general direction we are striving for.

In reality, you probably have some kind of user / role system or user / group system. To be able to view sensitive information, you must be a member of a specific role or group. Each of them can have its own specific set of representations and commands. It is not necessary to denalize data. It could be like simpe how to handle SQL-Views:

• CustomerDetailsForSupportStaff
• CustomerDetailsForSupportExecutive with unmasked SSN
• CustomerListForSupportStaff
• CustomerListForSupportExecutive with customer earnings totals
• and etc.