title: CQRS or App Service?
body: <p>So I like the concepts of CQRS in our application, mainly because we already support event sourcing (conceptually, not following any prescriptions that you see out there).  However, it really seems like CQRS is geared toward Big Data, Eventual consistency, that kind of thing.  We are always going to be a Relational DB app, so I am not sure if it fits.</p>
  
  <p>I also have concerns because I think I need to do some special things in my app layer.  When doing a read, I need to enforce security and filter data, things that are traditionally implemented in the application layer.</p>
  
  <p>My first question is, does my app fit (a traditional MVC / Relational DB app)?  Or does it make more sense to have a traditional app layer and use a DTO Mapper?</p>
  
  <p>My second question is, does it make sense to issue commands to your domain model out of a traditional application layer?  I like the idea of commands / command handlers and eventing.</p>
  
  <p>Let me clarify my question.  I have concerns around data filtering that are tied to authorization.  When a user requests data, there has to be a filter that restricts access to certain data elements by removing them all together (So they are not returned to the caller), hiding the values, or applying masks to the data.  In a contrived example, for a Social Security Number, the user making the request may only be able to see the last 4 numbers, so the result would appear like ###-##-1234.</p>
  
  <p>My assertion is that this responsibility goes in the Application layer.  I consider this an aspect, where all responses to queries or commands have to go through this filter mechanism.  Here is where my CQRS naivity shines through, perhaps it is that commands never return data, just pointers to data that are looked up through the read model?</p>
  
  <p>Thanks!</p>