Fat Controller CQRS Diet

Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.

Learn more about Software Architecture & Design.
Join thousands of developers getting weekly updates to increase your understanding of software architecture and design concepts.

Leave this field empty if you're human:

I’ve been meaning to create a sample application that uses the MediatR library to dispatch command and queries.  All of this organizing and writing your code in vertical slices rather than layers.

Why?

I can only speak from my experiences and how I came to applying CQRS with mediator pattern.  Hopefully you can can relate and translate it to your own code base and determine if it is a right fit for you. And that’s really important.  Is it a right fit for your application. What this series will demonstrate is not to be used as silver bullet. Nor should it be used everywhere. My intent with this series is to show how to use command and queries to decouple your application from you web framework. And that’s exactly how I came to using command and queries.  By realizing I was building an application that was incredibly tied to my web framework.  I had little ability to take any code and easily move it around.

Fat Controller

Over time, my web application started to becoming was a collection of massive controllers.   They did everything from being HTTP endpoints, basic data validation, data access, business logic, authorization and probably had a pile more responsibilities.

Multiple Uses

As mentioned before with my fat controllers, I had no ability to reuse code in any meaningful way.  A lot of the code lived in controllers.  If by chance it wasn’t in a controller, it likely had some dependency on the MVC framework in some way. Why is that problematic? Because I wanted to reuse some of these features in a new application that was being developed as a native Windows app.

Hiding Use Cases

I remember watching a video from Uncle Bob where he talked about how an MVC applications using a specific framework all looked the same and did not describe at all what the application did. What were the actual uses cases? What features did this application provide? The project layout and structure were all the same. Two applications that provided completely different functionality but were structured and organized the same way. This rang very true to me at the time.  I was hiding my uses cases by burying and coupling them to a web framework.

Music Store

Instead of writing an demo application from the ground up, I figured it would be a good idea to take an existing demo app and convert it using commands, queries and features slices. I’m going to use the ASP.NET MusicStore sample application (.NET Core), since it has both a combination of HTML views and JSON endpoints.

• Part 1: Simple Query
• Part 2: Simple Command
• Part 3: Command Pipeline
• Part 4: Notifications
• Part 5: Vertical Slices
• Part 6: Trade-offs

If anyone has any other suggestions or recommendations to a different sample application to use, please leave comment or let me know on twitter.

Follow @codeopinion