Mediator between Integration Boundaries

Integration BoundariesIf you have followed my Fat Controller CQRS Diet series, you will see that I use the mediator pattern.

More specifically I use MediatR library in all the code examples.

I recently gave a talk at CodeMash 2017 with the same title.   It went a bit more in depth about why and where I use the mediator pattern.

Integration Boundary

I want to decouple my application from the framework I’m using. The mediator pattern is one way of achieving that.

My code should be be my code.  Not littered through framework code.

Generally, I don’t want to have any dependencies on MVC, Web API, WFP, WinForm or whatever the top layer framework is that I’m using.

If I’m using ASP.NET MVC or Web API as my frontend to expose my application, I want to leverage it for what it’s good at.  The various aspects of the framework such as routing, view rendering, serialization (possibly) but without coupling my code to those.

Context is King

I generally don’t think in black or white when it comes to developing software.  Context is always king.

Making decisions around context is really important.

How do you know if you should decouple yourself from your framework?


Are you creating an application that is likely going to be used for many many years?

Does it have high value to it’s users?

Is it only throw away to validate an idea and going to last 6 months?

How large is the application, in terms of length of time to develop?  Could you rewrite it quickly?

Are you developing an application with a web interface or are you developing a web application?


All these questions and many more really matter in determining how far you should decouple from your web framework.

I love hearing your comments, questions and feedback!  Please post a comments or on Twitter.

Conference Speaking Experience: CodeMash 2017

CodeMash 2017At some point in 2016 I decided I wanted to submit talks to a few large conferences.  I’ve done talks at various small user groups, but nothing more than 30 people.

The main reason to submit to larger conferences was just for the new experience.  It’s something that is completely out of my comfort zone to speak in front of a large group.

I really wanted to see if speaking at conferences was something I would enjoy or not.

Although I’ve realized that it’s really easy for me to talking about software and especially the areas that I’ve grown to enjoy.

CodeMash 2017

I submitted 3 talks for CodeMash 2017.  One of which was my talk “Fat Controller CQRS Diet“.  Here’s the abstract.

Do your controllers need to go on a diet?

Fat controllers can quickly lead to tight coupling by the abundance validation, business logic, and data access. Thin out your controllers by only using your web framework for what it’s good at: HTTP, Routing, and Serialization.

Attendees will learn to how to organize code by feature by leveraging CQRS and the Mediator pattern to decouple your core business capabilities from your web framework.

Once the call for speakers were starting to get announced, I received an email saying this talk submission was accepted.


At first it was pure excitement that one of my talks was accepted.

Once the initial surprise wore off, it turned to to pure confusion.  I couldn’t believe I actually submitted let alone was accepted.

I had 3 months to put together and prepare of my first conference talk.


My talk wasn’t really anything new to me.  My initial vision was really talking about my experiences and journey in writing various web apps my entire career.

Those experiences which led to me to current day of applying CQRS along with vertical feature slices.

I first worked through creating a slide deck that were just talking points initially.   I was constantly thinking about my talk and how I could build a story around the abstract.

User Group

I did a really rough version 1 of the talk at a local user group.  It was really more of a discussion than an actual talk.

But it gave me some great feedback about some of the rough ideas that I had going in.   I will definitely leverage doing this again as it was invaluable.


Once I took the feedback from the talk at the local user group, I started practicing the timing and length of the talk to the desired 50-60 minutes.  I did this by recording the talk along with slides on my machine.  I would painfully listen back and take notes about my pace, crutch words and any other hiccups.

More Feedback

Once I recorded and practiced enough where I wanted more feedback,  I did a final recording and sent it out to a few people.

They not only provided some real constructive feedback but also gave me a lot of confidence that my earlier practice was worth it.

Again, this feedback was really valuable and made its way as changes to my final talk.

It’s go time

I’m a pretty nervous and anxious person.  Anytime I have to do something out of my comfort zone, I get very nervous.

What’s really surprising to me, is although I was a bit anxious the couple days and hours leading up to my talk.  I was surprisingly not really nervous.

I was fairly calm.  I was confident because I knew I was prepared.

Overall I felt the talk went exactly as I had prepared.  The experience was something I really enjoyed.  I spoke with many attendees after the session to answer some other questions and go in a bit deeper.

Shout Out

A sincere thank you to the following for really helping me.

CodeMash for accepting and giving me the opportunity as a first time speaker.  And to all the attendees who packed the room!  This conference is so well put together and organized it blows my mind.  I would highly recommend attending this conference.   Easily the best conference I’ve been to.   The venue at the Kalahari is perfect. I brought my entire family with me and they had a blast at the Kalahari.

Reid Evans for taking the picture above during my talk and providing great feedback.

Joseph Woodward for helping and giving me feedback with my abstract.

Dave Rael and Shawn Rakowski for providing constructive and useful feedback that may its way into the final talk.


I love hearing your comments, questions and feedback!  Please post a comments or on Twitter.

MediatR Behaviors

MediatR BehaviorsI was happy and surprised to see that MediatR v3.0 was released yesterday.  One of the new features, which I was really looking forward to are pipeline behaviors.

A pipeline behavior is an implementation of IPipelineBehavior<TRequest, TResponse>. It represents a similar pattern to filters in ASP.NET MVC/Web API or pipeline behaviors in NServiceBus.


There are a couple major breaking changes to v3.  All of them I’m fairly happy about actually.


There is no distinction between sync, async (cancellable) requests or notifications.

You simply implement either IRequest or INotification.

You must still create the appropriate handler via either IRequestHandler, IAsyncRequestHandlerICancellableAsyncRequestHandler.


To send a request or publish a notification simply use Task Send(IRequest) or Task Publish(INotification)

No longer does it have the “Async” convention of appending to the method name.  I know this is often debated about this convention.  I don’t mind it at all since there are no sync methods.


The new addition is the interface IPipelineBehavior<TRequest, TResponse>

This allows you to create implementation(s) that will invoked in the order they are registered with your container (returned from the MultiInstanceFactory delegate).

The simplest implementation, that does nothing but call the next possible behavior.

You can see how you can use this to create Pre and Post behaviors to create a pipeline.

Pre & Post Processors

Thankfully, these have already been created and built-in to v3.

RequestPreProcessorBehavior<TRequest, TResponse> and RequestPostProcessorBehavior<TRequest, TResponse> to the rescue.

These can be used to implementing the appropriate interface of IRequestPreProcess<TRequest,TResponse> and IRequestPostProcessor<TRequest,TResponse>

Note: Be sure to register your  IRequestPreProcess<TRequest,TResponse> and IRequestPostProcessor<TRequest,TResponse> as well as RequestPreProcessorBehavior<TRequest, TResponse> and RequestPostProcessorBehavior<TRequest, TResponse>  with your container.

Test Drive

I figured I would use my ASP.NET Core MVC Music Store application as a test bed.

You can refer to my Fat Controller CQRS Diet: Command Pipeline post to see how created a pipeline in MediatR v2.  It involved creating wrapper/decorator with StructureMap.

This is incredibly straight forward and does all the heavy lifting that the pipeline decorator that I created previous.

For our MusicStore app, we can change our AddToCart for logging to be done like this.

The above code completely removed my need for my custom Pipeline decorator using StructureMap.  Win.

ASP.NET Extension

If you are using ASP.NET Core, check out the MediatR.Extensions.Microsoft.DependencyInjection v2.x package.  It has also been updated to support MediatR v3.

It adds several extension methods, one of which is IServiceCollection.AddMediatR(Assembly) to register all the Handlers and Pre/PostProcessor in a given assembly.


Are you using MediatR?  Do you plan on upgrading to v3?  I love hearing your comments, questions and recommendations!  Please post a comments or on Twitter.