Sponsor: Using RabbitMQ or Azure Service Bus in your .NET systems? Well, you could just use their SDKs and roll your own serialization, routing, outbox, retries, and telemetry. I mean, seriously, how hard could it be?
Developing and thinking about features not layers is something I’ve moved towards over the last several years. I’ve mentioned it in several blog posts and I don’t think I ever explicitly created a post about it.CQRS
The real enabler has been CQRS. For those unfamiliar with CQRS or if you think it’s complicated, let me share a quote from Greg Young:CQRS is simply the creation of two objects where there was previously only one. The separation occurs based upon whether the methods are a command or a query (the same definition that is used by Meyer in Command and Query Separation, a command is any method that mutates state and a query is any method that returns a value).That’s it. It’s nothing more complicated than that. I think where the confusion lies is a lot of articles, blog posts, etc where the content describes much more than CQRS. CQRS is not event sourcing. CQRS is not domain driven design. CQRS does not mean multiple data stores. CQRS does not mean using a service bus. CQRS does mean having eventual consistency. CQRS is simply the creation of two objects where there was previously only one.
Features vs Layers
For me a feature in the technical sense is a command or a query. It could also be a combination of a few put together. I often have commands and queries dictate on their own how they are layered inside. This means that an individual command decides how it may do data access. It may not be a shared concern between another command. For comparison, here’s is how I visualize the difference.Layered

CQRS
