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

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.

  1. Why do I have a single controller SENDING messages (commands), and READING (reporting) data?
  2. 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.


Posted 06-24-2010 4:00 PM by Michael Nichols
Filed under: ,

[Advertisement]

Comments

Rob Eisenberg wrote re: Notes From A Project Applying Domain-Driven Design, Event Sourcing and CQRS : Part 3 – Messaging In Web Applications
on 06-24-2010 10:38 PM

Would love to hear more about how your POST-REDIRECT-GET implementation works on top of MVC. We've used a command/query type pattern on most of our MVC applications, but we've done it with an in-process synchronous bus. So, I'd be really interested to see what you've done to make the async pattern nice.

Michael Nichols wrote re: Notes From A Project Applying Domain-Driven Design, Event Sourcing and CQRS : Part 3 – Messaging In Web Applications
on 06-24-2010 11:46 PM

@Rob

I have an implementation that has worked okay so far, but I am redoing all these bits . I'll post what I have an then what I am leaning towards.

Henning Anderssen wrote re: Notes From A Project Applying Domain-Driven Design, Event Sourcing and CQRS : Part 3 – Messaging In Web Applications
on 06-25-2010 7:14 AM

You should read Jimmy Bogard's post on commanding from action results. www.lostechies.com/.../dependency-injection-in-asp-net-mvc-action-results.aspx

Very elegant solution, and I've been thinking about the same things myself for my current project.

Michael Nichols wrote re: Notes From A Project Applying Domain-Driven Design, Event Sourcing and CQRS : Part 3 – Messaging In Web Applications
on 06-25-2010 12:01 PM

@Henning

Thanks for the link. His solution is a partial of IDynamicAction in MonoRail. The only thing that gets hairy is when you need to respond using args from a response; ie, the 'Id' of some event.

Sampy wrote re: Notes From A Project Applying Domain-Driven Design, Event Sourcing and CQRS : Part 3 – Messaging In Web Applications
on 06-25-2010 2:06 PM

The more I think about Controllers in ASP.Net MVC, the more I think that they aren't really objects in the traditional SOLID sense but more handy containers to keep certain action methods together. If I wanted, I could have a 1:1 relationship between action method to controller (maybe 2:1 for cases where I display a form then accept a response). The main reason I keep controllers around is to help me organize my action methods into groups that make sense to me.

Before I was all about "1 controller per entity" stuff but after I started really trimming down my controller bodies, I started to worry a lot less about that "purity" ideal and more about practical organization for my team. The action methods can move from Controller to Controller so effortlessly that I just put them where they make sense and if I want to move them I do.

I'm Mike Sampson and I have an AdminController and I'm proud of it :P

zihotki wrote re: Notes From A Project Applying Domain-Driven Design, Event Sourcing and CQRS : Part 3 – Messaging In Web Applications
on 06-30-2010 8:02 AM

Your approach looks good. It should work perfectly for standard cases when on GET you load data and on POST you update/delete/create. But what about cases when for security reasons on POST request I want to get data? For example some JSON data.

Mike wrote re: Notes From A Project Applying Domain-Driven Design, Event Sourcing and CQRS : Part 3 – Messaging In Web Applications
on 06-30-2010 11:14 AM

@zihotki-

I am following a convention that any action starting with 'Execute' gets routed to the current controller + 'Command'. So 'ProjectController' becomes 'ProjectCommandController' with the 'ExecuteCreate' method.

If you want to step around that convention just don't start the action with 'Execute'...it will just pass through.

Jak Charlton wrote re: Notes From A Project Applying Domain-Driven Design, Event Sourcing and CQRS : Part 3 – Messaging In Web Applications
on 07-11-2010 10:50 PM

I have done similar, but by actually making all controllers single action (bypassing the MVC framwork's built in conventions)

So, in effect all POSTs are separate from all GETs anyway, it just reinforces the "Command" method approach

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)