Notes From A Project Applying Domain-Driven Design, Event Sourcing and CQRS : Part 3 – Messaging In Web Applications

Michael Nichols — Thu, 24 Jun 2010 23:00:08 GMT

Today I am not strictly mouthing off strictly about the three things in the title, but more about the side-effects of their joy in a web application.

Two things have made me feel dirty while implementing a messaging solution in a web application while adhering strictly to Command-Query Separation.

Why do I have a single controller SENDING messages (commands), and READING (reporting) data?
What patterns exist beyond just a correlation id for notifying the user when their commands’ processing are completed?

The first one is the one on my mind today as I am testing the bits that send the messages to my Win service hosting my domain. The second one I will deal with in the next post.

My controllers look pretty typical:

public class ProjectController : Controller
{
    IExecuteCommands bus;
    public void ProjectController(IExecuteCommands bus)
    {
        this.bus=bus;
    }
    public ActionResult New()
    {
        return View(new NewProjectViewModel() };
    }
    public ActionResult Create(CreateProjectCommand project)
    {
        bus.Send(project);
        return this.RedirectToAction<MessagingController>(c=>c.Wait(this.ConversationId));
    }
}

My controllers are either reading or writing…why do I have the same controller doing both? The semi-optional service dependencies are a smell that I am putting too many responsibilities here. I already adhere to POST-REDIRECT-GET convention, so it seems unnecessary.

Why not split this into :

ProjectController = Only GET requests
ProjectCommandController = Only POST requests

Since the majority of actions are reads and we want take of advantage of conventions in frameworks like MVC for urls, we can just pull our state-changing actions into a separate controller and append the name with ‘Command’.

Commands abiding by some kind of naming convention, perhaps ‘Execute’ prefix, would simply be routed to the [ControllerName] + ‘Command’ Controller.

This would make testing simpler since I don’t have to satisfy unneeded dependencies for action testing.

What pitfalls do you see in making this a standard practice? Have you tried this and found problems? I’d like to hear any criticisms and comments you might have.

Mike Nichols - Son Of Nun Technology : Messaging

Notes From A Project Applying Domain-Driven Design, Event Sourcing and CQRS : Part 3 – Messaging In Web Applications