With the MediatR v3, there is the ability to create your own request pipelines. To help out of the box, there are some predefined behaviors to help out with commen tasks such as pre and post request. These are RequestPreProcessorBehavior<,> and RequestPostProcessorBehavior<,>

I’ve blogged about the new behaviors before but you can do it more generically.

Cross Cutting Behavior

I was looking at the pipeline to handle cross-cutting concerns like logging and metrics, which I would want on each command/query.

— Scott Banwart (@sbanwart) September 6, 2017

Logging

Pretty typical scenario of wanting to log incoming requests.   One common use case would be to store the incoming requests as a message store.

View the code on Gist.

Registration

The next piece of the puzzle is making sure you register the RequestPreProcessorBehavior<,>with the DI container you are using with MediatR.  In the case of StructureMap that looks like:

View the code on Gist.

Result

The end result is that any Request will run through the new RequestLogger.  You could log to a provider, serialize to your own data store, etc.

Speaking of storing, I’m in the middle of implementing a message and command store in MySQL for Brighter, so stay tuned for a bunch of blog posts related it soon!

What type of pipelines are you using with MediatR?  Do you have any type of command or message store?  Let me know in the comments or on Twitter.

The post Logging MediatR Requests appeared first on CodeOpinion.

I just returned from Denver, Colorado, where the first Explore DDD conference was held.  I originally heard about it earlier in the year on Twitter via the organizer Paul Rayner and decided to submit a couple abstracts for the CFP.

Fat Controller CQRS Diet

The talk that was accepted and which I delivered on Friday morning was my Fat Controller CQRS Diet talk.  The talk revolves around trying to decouple your application from top I/O layer or framework.  More info on the talk can be found in my series of blog posts as well as a episode of Software Engineering Daily podcast.

Domain Driven Design

I stumbled upon Domain Driven Design somewhere around 2010.  I actually found it because of watching a talk online from Greg Young making some indirect references to Domain Driven Design and CQRS.  The talk caught my interest and within no time I was captivated by DDD and CQRS.  I instantly went and purchased the book.  That was a very significant point in my software development career.

Explore DDD

The speaker lineup at this conference was simply incredible.  Eric Evans, Rebecca Wirfs-Brock and Ward Cunningham were the keynotes.  Crazy.

I cannot really believe that I was chosen to speak at such a conference. Imposter Syndrome was maxed out to 11.

It didn’t take too long to have some conversations at the conference to realize that I had different experiences and views that proved to be valuable.  This didn’t knock down the imposter syndrome completely, but definitely lowered it a just a tad.  On the other hand, the amount that I learned from discussions and talks were like no other conference.

Community/Family

This really summed it for me.  There was a real sense of community/family.  I can’t really put my finger on why that is but I have a few guesses.

Conference Space/Location

Incredible.  38th Floor of the Grand Hyatt, looking over downtown Denver.  The floor itself was broken down into 3 track rooms, general gathering room where food was served, as well as a unique blue track room.  The blue track was reserved for spontaneous modeling, discussions, problem solving, whatever.  I actually had several interesting discuss here and it was kind of a good place for the “hallway” track in some respects.

Paul Rayner

The conference kicked off on Wednesday evening with the keynote by Eric Evans.  Paul spoke to intro the conference as well as each day with some house keeping notes.  I felt the way Paul gave such a calm welcoming, really set a tone for the entire conference.

Thank You!

Hands down an awesome conference.   Thank you to Paul for organizing an incredible event and selecting my talk.  All the attendees and speakers (from all over the world!) for making it feel like a family.

I highly recommend attending this next year.  I hope to see you there!

The post Explore DDD 2017 Review appeared first on CodeOpinion.

I’ve been wanting to explore Brighter for awhile, probably over a year.  I figured I’d try something new this time around and actually explore it by contributing to the project itself.  I noticed there were no Command and Message Stores yet supporting MySQL.  Turns out it was pretty straight forward to port the Sqlite Message & Command over to MySQL.  So that’s what I did, created a Brighter MySQL Command Store.

Brighter

First, if you’re unfamiliar with Brighter, here’s a quick description:

This project is a Command Processor & Dispatcher implementation that can be used as a lightweight library in other projects.

It can be used for implementing Ports and Adapters and CQRS (PDF) architectural styles in .NET.

In addition, Brighter supports Distributed Task Queues. As such it can be used to improve performance by introducing concurrency using a queue, and/or as an integration strategy between Microservices using messaging via a lightweight broker.

I like to think of Brighter as your possible next step from MediatR.  Since everything in MediatR is in process, which is great in many situations, it can also be less ideal in others.  When you need task queues, retry,  and circuit breaker type functionality is where Brighter can help right out of the box.

Command Sourcing

Don’t confuse Command Sourcing with Event Sourcing.  If you are, check out the Brighter docs that go into it a bit to clarify.

Any command dispatched with Brighter can be stored.  It’s actually pretty straightforward to setup.  I’m going to use the new MySqlCommandStore that I recently created as the example.

Register IAmCommandStore

First thing you need to do is register the MySqlCommandStore as a IAmACommandStore and/or IAmACommandStoreAsync, in the container you are using in your HandlerConfiguration.  Here’s a modified version of the HelloWorld sample.

For reference, the two parameters in the MySqlCommandStoreConfiguration are the connection string and the table name.

View the code on Gist.

UseCommandSourcing Attribute

Second and last step is to add the UseCommandSourcing attribute to the command handler you want to persist into command store (MySQL table).

View the code on Gist.

Result

When I run the sample app, here is the console output:

And the resulting record now stored in our MySQL database:

More

I plan on blogging more about Brighter in the near future.  Are you using Brighter?  Are there any specific features or topics you would like me to cover?  Let me know in the comments or on Twitter.

The post Brighter MySQL Command Store appeared first on CodeOpinion.

I’ve been wanting to take a deeper dive into Microsoft Orleans for awhile now.  With the next release targeting .NET Standard 2.0, it felt like an great time to do it.  This is the first blog post in a series that will go beyond a simple Hello World.  The plan is to make this a practical Microsoft Orleans guide to follow along with.

Microsoft Orleans

If you aren’t familiar with Orleans, here’s a brief overview.

Orleans is a framework that provides a straightforward approach to building distributed high-scale computing applications, without the need to learn and apply complex concurrency or other scaling patterns.

Or maybe you have heard Orleans is an Actor model framework.  Well…

Implementation of Orleans is based on the Actor Model that’s been around since 1970s. However, unlike actors in more traditional actor systems such as Erlang or Akka, Orleans Grains are virtual actors. The biggest difference is that physical instantiations of grains are completely abstracted away and are automatically managed by the Orleans runtime. The Virtual Actor Model is much more suitable for high-scale dynamic workloads like cloud services and is the major innovation of Orleans. You can read more details in the Technical Report on Orleans.

Docs

I have to give it to the Orleans team.  Their docs seem fantastic.  I’ve read over most of their Step-by-Step guide and feel like there’s a lot of insight being shared.  There’s a section about Concurrency that has some great code samples that gives with code samples a deadlock scenario.  I found reading over these docs to be really helpful in understanding and just looking at small code samples.

Event Sourcing

One aspect that I find interesting is having a grain manage it’s state being event sourced.

Event sourcing provides a flexible way to manage and persist grain state. An event-sourced grain has many potential advantages over a standard grain. For one, it can be used with many different storage provider configurations, and supports geo-replication across multiple clusters. Moreover, it cleanly separates the grain class from definitions of the grain state (represented by a grain state object) and grain updates (represented by event objects).

My plan is to use event sourcing as grain state and persist events to Event Store.  Luckily I’m familiar enough with Event Store however have to do more reading on if there is an existing implementation or have to roll my own.

Sample Application

As with other blog series I’ve done in the past, I find it helpful to take an existing OSS application that I can fork and use as a base.

Do you have a suggestion about an application I can fork to use as a base?  I’d love to hear your suggestions.  Let me know Twitter or in the comments.

The post Practical Microsoft Orleans appeared first on CodeOpinion.

You’ve run into it.  MediatR throwing an InvalidOperationException when you didn’t have a matching handler for a request.   There’s a fairly simple solution to prevent this: Find MediatR Requests without Handlers.

So here’s some quick code you can throw in a unit test to verify you don’t have any missing handlers.

Find MediatR Requests without Handlers

View the code on Gist.

The above code uses reflection to get all the IRequest<>, RequestHandler<> and RequestHandler<,>.  Also worth mentioning it leverages Autofac for the IsClosedTypeOf method in the linq query.

Usage

Here’s a quick unit test that shows it’s usage for finding Requests without any handlers.  In the sample below I have two Requests without Handlers: MyRequestWithoutHandler and MyRequestWithResultWithoutHandler

View the code on Gist.

Source

All the source code for my example is available on GitHub if you want to try it yourself.

Another useful test would be to verify that your container actually has the the request and behavior handlers registered correctly.  Another post to come with that.

Always love hearing your comments.  Please post them here or on Twitter.

The post Find MediatR Requests without Handlers appeared first on CodeOpinion.

Finding good sample applications if pretty difficult, if not impossible.  Most are small Todo style applications that are generally very CRUD based.  Thankfully Microsoft has created the eShopOnContainers a Microservice based .NET Core Sample Application.

.NET Core reference application, powered by Microsoft, based on a simplified microservices architecture and Docker containers.

This reference application is cross-platform at the server and client side, thanks to .NET Core services capable of running on Linux or Windows containers depending on your Docker host, and to Xamarin for mobile apps running on Android, iOS or Windows/UWP plus any browser for the client web apps.

The architecture proposes a microservice oriented architecture implementation with multiple autonomous microservices (each one owning its own data/db) and implementing different approaches within each microservice (simple CRUD vs. DDD/CQRS patterns) using Http as the communication protocol between the client apps and the microservices and supports asynchronous communication for data updates propagation across multiple services based on Integration Events and an Event Bus (a light message broker, to choose between RabbitMQ or Azure Service Bus, underneath) plus other features defined at the roadmap.

eShopOnContainers

Here’s a development environment overview of the of the eShopOnContainers app.  I just want to point out a few pieces that I thought were well done in this sample.

Service Autonomy

Each service (Identity, Catalog, Ordering, Basket, Marketing, Locations) is autonomous.  It owns its own data(store) and does not have any dependencies on any other services.  In order to communicate with other services, it uses an event-driven model via publish/subscriber on an event bus of RabbitMQ or Azure Service Bus.

Each service does contain its own HTTP API that provides functionality such as retrieving data as well as performing specific actions.  For example, the Ordering service contains an API project that has HTTP resources for retrieving orders as well as canceling an order.

View Composition

Since each service provides its own HTTP API for retrieving specific data owned within that service, you ultimately need to compose your view from multiple services.

Backend-For-Frontends (BFF) patterns are used to provide a single API backend for a specific client type.  For example, the MVC and SPA apps use the Web-Shipping and Web-Marketing BFF while the Xamarin mobile app uses the Mobile-Shopping and Mobile-Marketing BFF.  Ultimately these BFF make HTTP calls to the needed services to compose the data required for the client.

More

I highly recommend checking out the application and digging in a bit.  There are many different services and each has its own individual architecture within it.  Such as the Ordering service using CQRS via the MediatR library in it’s HTTP API.  It also uses some technical DDD patterns as well.

If you’re interested in the Backends-For-Frontends, I recommend checking the post by Sam Newman and Chris Richardson.

Although a tad outdated, Particular have also a fork of eShopOnContainers but modified to run on top of NServiceBus.

If you know of any other solid sample applications beyond To Do lists, please let me know in the comments or on Twitter.

The post eShopOnContainers a Microservice based .NET Core Sample Application appeared first on CodeOpinion.

There are many misconceptions about CQRS. It’s often referenced alongside other patterns that can make it seem difficult and complicated. Is CQRS complicated? No. CQRS is simple. Really simple.

What is CQRS?

First, let’s tackle at the very core what CQRS actually is.

CQRS stands for Command Query Responsibility Segregation and was coined by Greg Young. CQRS is related to CQS (Command Query Separation) principle by Bertrand Myer which states:

Every method should either be a command that performs an action, or a query that returns data to the caller, but not both.

In other words, a command is a method that mutates state and query is a method that returns state. A method generally doesn’t do both, but there are exceptions to this rule.

CQRS takes CQS a step further by separating commands and queries into different objects.

To use an exampling in C#, here is a shipment class has two methods. It applies CQS, in that each method either performs an action or returns data.

CQRS Applied

If we take the above class and were to apply CQRS, we simply just need to turn this into two objects. One object would be used for mutating state (ShipmentCommand) and the other object for returning state (ShipmentQuery).

That’s it. You’ve just applied CQRS. Wasn’t that totally unexciting?

Misconceptions

I suspect the reason for the misconceptions about being complex and difficult stems from people seeing a diagram like this:

If you search google images for CQRS, you are bound to find almost every diagram that looks like the one above or some variation of it.

Is the diagram applying CQRS? Yes.
Is the diagram only applying CQRS? No.

When you hear talks or read about CQRS you are often also hearing about a bunch of other patterns or technology. Mainly those that in attempted to be represented in the diagram above.

You do not need:

• Message Broker or Bus
• Messaging
• Domain Model
• Domain Events
• Event Sourcing
• Eventual Consistency
• Separate Models for Reads and Writes
• Domain Driven Design

Enabler

I often say that CQRS is an enabler. It enables or facilitates using other patterns that often fit well together. This is why you often see CQRS and Event Sourcing applied together.

CQRS is not Event Sourcing nor does it require you to use Event Sourcing. CQRS simply fits well and enables you to apply Event Sourcing.

Fat Controller CQRS Diet

I’ve blogged a bit about how to implement CQRS without any of the other fluff. You can check out my Fat Controller CQRS Diet blog series as well as a related talk:

More

I plan on breaking down some of the misconceptions and other aspects that are often lumped in with CQRS in coming posts.

If you have any questions or comments, please let me know on twitter as I will focus my posts on those questions and comments.

The post Is CQRS Complicated? appeared first on CodeOpinion.

This post is in my Fat Controller CQRS Diet series. It demonstrates how to thin your controllers by implementing commands and queries using the MediatR library.  Specifically in this post, I’ll look at organizing your code by vertical slices.

I’m converting the MusicStore application that’s using ASP.NET Core MVC.   All the source code is available on GitHub.

If you’re new to this series, here are earlier posts to get up to speed:

1. Overview of Series
2. Simple Query
3. Simple Command
4. Command Pipeline
5. Notifications

Organize by Feature

Feature Slices or Vertical Slices are the terms I’ve heard the most for what I call Organize by Feature.

I’ve just always characterized as organizing all relevant code and files from a command or query into a specific folder or hopefully single file.

I generally stay away from creating layers so the term Vertical Slices does make a lot of sense.

Whatever our feature slice is, it surely makes sense to keep all that code together.

Single File

If you’ve seen the code related to my Command Pipeline or Notifications posts, then you should already be able to tell where I’m heading in terms of organization.

I generally like to keep the command/query and it’s associated handler all within the same file.  In the case of our logging handler, I was also keeping it in this file.

Pretty simple.  One file for everything related to a command or query.

Controllers & Views

Well almost.  What I hadn’t really moved were the controllers or views.  So let’s do that now.

Controllers are pretty easy since by default they can live anywhere within your project. ASP.NET MVC Core will just pick them up.

Let’s work on our Home Query.  We will simply create a HomeController within our Home.cs file that currently contains our query and our handler.

View the code on Gist.

Because we are no longer using the default routing, I’ve added the HttpGet attribute to the method to keep the route intact to what it was prior.

View Locator

By default, ASP.NET Core MVC will look in the ~/Views/ folder with default conventions.  But we want to put our view right along side our Home.cs file in our Features folder.

So I’ve moved all of the view files into our Features folder.  Our solution now looks like this:

In order to tell ASP.NET where our views are now at, we can implement the IViewLocationExpander

View the code on Gist.

Now in the  IServiceProvider ConfigureServices(IServiceCollection services) method from our Startup.cs, we can can configure to use our new locator.

View the code on Gist.

That’s it!

We now have one file that contains our controller, query and handler.  And right along side it we have our associated view.

Comments

All the source code for this series is available on GitHub.

I love hearing your comments, questions and recommendations as it usually leads me down to other blog posts.  Please post a comments or on Twitter.

Follow @codeopinion

The post Fat Controller CQRS Diet: Vertical Slices appeared first on CodeOpinion.

In my Fat Controller CQRS Diet series, I’ve shown the mediator pattern and the MediatR library. After a recent discussion with Reid Evans, he made me realize I haven’t really described the trade-offs.  This post is going to focus on trade-offs and an alternative to using the mediator pattern.

If you’re new to this series, here are earlier posts to get you up to speed:

1. Overview of Series
2. Simple Query
3. Simple Command
4. Command Pipeline
5. Notifications
6. Vertical Slices

Coupling

With the mediator pattern, communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

For me the purpose of using the mediator pattern is to limit the coupling between integration boundaries.  Those boundaries in my applications are typically the Web/UI Framework and my core application.

This means I’ll have my controllers take a dependency on the mediator and not my core application.

View the code on Gist.

Runtime Resolution

The downside to this that there is no compile time type checking.  When the mediator is invoked at runtime, it could fail to send the request if there is no handler defined.

In the code example above, if there is no IAsyncRequestHandler<Home, List<Album>> then an exception will be thrown on _mediator.SendAsync(new Home());

Coupling to Handler (or Interface)

We could get around this and get our type checking at compile time by having the request handler injected into our controller.

This is fairly reasonable since I often have one controller per command or query.  This then limits the dependencies I’d be putting into the constructor.

View the code on Gist.

Messaging

One aspect that I haven’t touched on (yet) in this series is about background processing and queues.  I really enjoy using Hangfire to create background jobs.   I’ve blogged about it before and how to integrate MediatR and Hangfire together.

The general approach I take is to use messaging between MediatR and Hangfire to keep it consistent on how commands or queries are made.  That means messaging with MediatR done in-process or done on out of process (on other machines) via Hangfire but routing them through MediatR.

Comments

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

Follow @codeopinion

The post Fat Controller CQRS Diet: Trade-offs appeared first on CodeOpinion.

I 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.

Changes

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

Messages

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, IAsyncRequestHandler, ICancellableAsyncRequestHandler.

Async

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.

Behaviors

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.

View the code on Gist.

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.

View the code on Gist.

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.

Comments

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.

Follow @codeopinion

The post MediatR Behaviors appeared first on CodeOpinion.

At 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.

Excitement

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.

Preparation

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.

Recordings

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.

Comments

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

Follow @codeopinion

The post Conference Speaking Experience: CodeMash 2017 appeared first on CodeOpinion.

If 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?

Questions

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?

Decoupling

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.

Follow @codeopinion

The post Mediator between Integration Boundaries appeared first on CodeOpinion.

I’ve blogged about the mediator pattern a lot.  Primarily because it’s been a good fit in several of the applications I’ve developed over the last few years.

Mediator Pattern

For those completely unfamiliar with the mediator pattern, here’s a brief summary:

With the mediator pattern, communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

Libraries

I’ve written my own implementations of the mediator library from project to project.  Once I finally found the MediatR library, I’ve pretty much been using it instead of my own.

In a recent post about MediatR v3’s new Behaviors, Daniel Little commented about his implementation called MicroBus.

I love checking out new libraries to see what’s out there.  I’ve gotten a lot of feedback about other OSS libraries and tools I’ve blogged about.

I figured this was a good opportunity to mention library that look pretty interesting and may be worth taking a deeper look at.

MicroBus

This library actually looks more like what I’ve built myself in the past.

The first thing to notice is there are two separate interfaces for defining a Command or a Query.

View the code on Gist.

There isn’t anything surprising when you look at implement your handlers.  It’s pretty straight forward and what you would expect.  Familiar things are nice.

View the code on Gist.

Cross Cutting Handlers

What’s really interesting is how it handles cross cutting concerns.  You can create global handlers via the IDelegatedHandler interface or create a pipeline with IPipeline interface.

View the code on Gist.

BusBuilder

Another interesting aspect is how you build up registering your handlers.  There is built in support for Autofac

View the code on Gist.

Comments

From the looks of it MicroBus looks like a pretty nice implementation of the mediator pattern with a lot of features people are looking for such as pipelines.

Check it out on GitHub.  It is a very active project (as of this posting).

If you want to see a real world demo, possibly of my MusicStore sample app but using MicroBus, please let me know!

If you have another library you would like me to blog about feel please let me know in the comments or on Twitter.

Follow @codeopinion

The post MicroBus: In-Process Mediator appeared first on CodeOpinion.

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

In the layered approach, we separate and organize our code by technical concerns.  Authentication, Business Logic Layer (BLL) and Data Access Layer (DAL) are all contained.  Once layer invokes the next.

CQRS

The difference in our CQRS approach is that our Commands and Queries contain the layers of technical concerns within them.  We don’t have layers spanning over the entire application.

This has some pretty profound implications in terms of being able to make different decisions in smaller units.

As well the biggest distinction is we can start thinking, developing and organize our code by business concerns rather than technical concern.

Organizing by Feature

If you want to see how this works in practice, I’ve blogged about writing your code this way.  Most of my sample code uses the MediatR library for handling things like Commands and Queries.

I recommend checking out my Fat Controller CQRS Diet: Vertical Slices post which demonstrates how to do this in ASP.NET MVC Core.

Testing

One aspect that took longer to come around was testing in the same manner.

Meaning, I start writing tests and thinking about them around my features rather than layers within a feature.

My new few series of posts will be around testing features / vertical slices.

I love hearing your comments, questions and recommendations as it usually leads me down to other blog posts.  Please post a comments or on Twitter.

Follow @codeopinion

The post Developing Features not Layers appeared first on CodeOpinion.

I recently got a really great comment from my post on using Query Objects instead of Repositories.  Although that blog post is now 2 years old, I still use the same concepts today in my applications.

What I thought may be relevant is to elaborate more on why and when I use the mediator and command pattern for the query side.

It may seem obvious on the command side, but not really needed on the query side.

Here a portion of the comment from Chris:

I’m struggling a bit to see the killer reason for using Query objects over repository. I can see the benefits of CQS but it’s this command pattern type implementation of the Q part I struggle with. I can see for Commands (mutators) the benefits of having separate handlers as you can use decorator pattern to wrap them with additional functionality e.g. Transaction, Audit etc.

However for queries I’m struggling to see why you wouldn’t just use a normal repository. Essentially your IQuery object defined what would be a method signature in the repository and the handler defines the implementation of the method. However at some point you have to compose the IQuery class to it’s handler either using a dependency injection framework or Mediator pattern as in your following blog.

Query Objects

The primary place I use query objects (mediator + command pattern) is when I want to be decoupled from an integration boundary.  Often times this is between my application and the web framework I’m using.

I view my query objects as my public API.

Which means I usually want to create a pipeline for those queries.  I will use a request pipeline for handling things such as authorization, validation and logging in the query pipeline.

Since this is the same implementation I use on the command side, it’s easy to use with library like MediatR which handles both commands and queries as a “Request”.

Repositories

I still use repositories, but just very differently than I did before.  Since my query objects are my public API, my repositories are generally only used internally within a the core of a given application (or bounded context).

My repositories are usually pretty narrow and also handle things like caching.

CQRS

There are many ways to implement the separation between reads and rights.  I’ve failed at making this point clear in many of my prior posts.

I’ve had a few encounters recently that make me feel like there’s still a lot of misconceptions about what people think CQRS is.  I’ll keep posting 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 all it is folks.  Not really that interesting.  What’s interesting are all the possibilities because of this simple idea.

How you implement that is up to you.

One of the ways I’ve been implementing this is with the Mediator + Command Patterns.  It’s not the only way!

Comments

How are you implementing the query side?  Always enjoy hear your feedback, commands and questions.  Please let me know on twitter or in the comments.

Follow @codeopinion

The post Queries with Mediator and Command Patterns appeared first on CodeOpinion.

We have all been doing “web services” forever.  My first introduction was in the late 90’s with XML-RPC and WDDX.  Followed up soon after with SOAP.  Good times.  Oh and remember WS-*.  Don’t remind me.

Why?

Over the last couple years, I’ve really taken an interest in HTTP APIs.

I’ve been meaning to post about my experiences developing an HTTP APIs.  It’s been an interesting last couple of years and I think there is quiet a bit to share.

Issues

I can only speak from my experiences and give some of the context about my situations.  Hopefully you can relate and translate it to your own projects and make a determination if what I struggled with is beneficial in your context.

There were four major pain points that I ran into developing our HTTP API and Clients.

• Unable to change internal data structures that got exposed/serialized to Clients
• Unable to change endpoint paths/routes
• Endpoint documentation (incoming and outgoing payloads)
• Workflow logic living on the client

HTTP APIs

Sometimes all you need is to do CRUD.  Sometimes that’s the last thing you should be doing.

Most examples and getting started tutorials usually demonstrate exposing your database structure and provide GET/POST/PUT/DELETE as away of performing CRUD.

You basically end up with HTTP endpoints that are a 1:1 mapping with a database entities.

This also makes it incredibly hard to change your API.

Go beyond serializing a database row into JSON

I’ve realized that developing an HTTP API is not much different than developing a regular HTML Website.

I started developing my HTTP APIs like I would if I were creating a static HTML or server side rendered HTML web application.  This means bringing the concepts we’ve been using for ages with HTTP and HTML such as links and forms.

(Un)Surprisingly, this lead to several benefits.  First, our API clients could consume our API with ease.  Second, they became dumb.  Workflow or business logic stayed on the server and didn’t leak to the client.

Series

This series of posts is going to cover some misconceptions I had in regards to HTTP APIs and REST.

Producing an HTTP API using Hypermedia and various media types.

Consuming an HTTP API that uses Hypermedia.

How you can use CQRS and Hypermedia together.

Similar to my Fat Controller CQRS Diet series, I’m going to convert an existing web application.   Currently I’m thinking of using the MVC Music Store again.  If anyone has any other suggestions or recommendations about this series, or the sample project to convert, please leave comment or let me know on twitter.

1. Building a Self Descriptive HTTP API in ASP.NET Core
2. Object as Resource
3. Hypermedia
4. Siren
5. HATEOAS
6. Hypermedia Clients

Follow @codeopinion

The post Building a Self Descriptive HTTP API in ASP.NET Core appeared first on CodeOpinion.

Projections are an important yet pretty simple concept when working with event-centric or event sourcing systems. The concept is to build a state from a stream of events. In my previous post, Event Sourcing with SQL Stream Store, I made a pretty basic projection to keep the current account balance. In this post, I’ll use Liquid Projections to accomplish the same task.

I recommend checking out my post on SQL Stream Store as I’m using the same example/demo application in this post.

Liquid Projections

Liquid Projection is a library for building projections. The concept and API are pretty simple, and I’ll cover the basics in this post.

First I’ll update my Demo Application to use the Liquid Projections NuGet package.

Event Map

The first building block is creating an event map. The idea is to map an event to an action that we want to be invoked when the event occurs. We can use the EventMapBuild<TContext> to create all of our event mappings. The TContext can be anything but I’ll be using it to mutate the state that represents the current balance.

As a refresher from my previous post, here is the Balance

Now using the EventMapBuilder<Balance> to handle the Deposited and Withdrawn events.

You’ll notice call Build() on the EventMapBuilder<Balance> which will return us the EventMap<Balance>. At this point, you can call Handle() to pass in the events incoming from our subscription with our current Balance.

Conditions

There are also some nice additions such as providing conditions for when to execute a map. For example, if you wanted to handle only deposited events where the amount was greater than 100.

Inheritance

There is also support for inheritance, which means since my Deposited and Withdrawn events inherit from the AccountEvent base class, I could also have done

Event Store Integration

The next on my list is write this up directly with to something like Event Store or SQL Stream Store. Stay tuned.

Check out Liquid Projections on GitHub for more.

All the source code shown in this post is available on GitHub.

If you’d like a more detailed contented related to various aspects of event sourcing, let me know in the comments or on twitter.

Related Links:

• Event Sourcing with SQL Stream Store
• EventStore for Orleans Grain Persistence
• EventStore Persistent Subscriptions Demo

The post Event Sourcing: Projections with Liquid Projections appeared first on CodeOpinion.

For many years now I’ve advocated not using the repository pattern on top of an ORM such as Entity Framework. There are many reasons why that I’ll try and cover throughout this post based on ways that I’ve seen it implemented. Meaning, this post is talking about poorly implemented approaches or pitfalls that I’ve seen.

To clarify, since this topic seems to really fire people up, I’m not saying that you shouldn’t use the repository pattern. I’m going to clarify why I don’t think under certain situations it’s very useful and other situations that I do find it useful.

This post was spurred on by a blog post and tweet:

IQueryable

The first thing I’ve seen with a repository is exposing IQueryable<T> (or DbSet<T>) from the underlying DbContext in your repository. This serves no purpose. It’s not abstracting anything at all.

What’s even worst is the consumers/callers don’t necessarily know at what point will they actually be retrieving data (doing I/O), unless you’re aware that the underlying IQueryable is coming from Entity Framework., Now when you call a method that materializes your query and actually hits the database (such as ToListAsync()).

Lazy Loading

Second, to this point is now if you have any type of navigation properties and are accessing IQueryable<T> from repository consumers, you must either eager load (via Include()) or have your consumers do the Include() or not realize all navigation properties are lazy loading.

Again, consumers are now aware of the underlying implementation that is Entity Framework.

IEnumerable

To overcome these issues, usually what comes next is avoiding the IQueryable<T> by returning an IEnumerable<T>.

The issue now is since you’re taking away control from the consumer, you must decide what data to Include() and Select() behind query methods.

What this often turns into is a pile of methods with various filtering parameters that could have been much easier expressed via a LINQ expression against the DbSet directly.

Query Objects

So if I don’t generally use the repository pattern, what do I use? Query Objects.

For querying, I’d rather have specialized objects that can return very specific data for the given use case. When implementing in vertical feature slices, as opposed to layers, each query is responsible for how it retrieves data.

The simplest solution is to use the DbContext and query directly.

The primary benefit is query objects only have dependencies that they actually require. Because each query object defines its own dependencies, you can change those dependencies without affecting other query objects.

A simple example of this is if you wanted to migrate from Entity Framework 6 to Entity Framework Core. You could migrate one query object at a time to EF Core instead of having to change over an entire repository that is highly coupled.

Testing

I can see the argument for using a repository because testing was difficult with EF6. However, with EF Core using the SQLite or the InMemory Provider, testing is incredibly easy.

I’ve written a post on how to use the SQLite provider with an in-memory database.

Testing a Query Object becomes incredibly easy without the need to mock.

Caching

Another argument for using the repository pattern is being able to swap out the implementation for a “cached repository”. I do use this pattern but in very select cases. Most times this is across bounded context were cached or stale data is acceptable.

If you decide to swap out the implementation of your repository, which was previously always hitting the database (point of truth) and now is using a cache implementation, how does that affect the callers? How quickly is the data invalidated?

Data can be stale the moment you retrieve it from the database, however adding caching to your repository without your callers knowing it can have a big impact on behavior.

Aggregate Root

One place I do often use a repository is when accessing an aggregate (in DDD Terms). My repositories often only contain two methods, Get(id) and Save(aggregateRoot).

The reason I do use a repository in this situation is that my repository usually returns an object that encapsulates my EF data model. I want it to fetch the entire object model and construct the aggregate root. The aggregate root does not expose data but only behavior (methods) to change state.

Repository Pattern Related

• Developing Features not Layers
• Fat Controller CQRS Diet: Vertical Slices
• Organize by Feature

The post Avoiding the Repository Pattern with an ORM appeared first on CodeOpinion.

Although Command Query Responsibility Segregation (CQRS) seems to be a term a lot of developers are aware of, I do think the majority have the wrong definition. Like many terms in the software development industry, things over time get confused, and then those confusing ideas propagate. These are the 3 CQRS Myths I see or hear the most often.

YouTube

Check out my YouTube channel where I post all kinds of content that accompanies my posts including this video showing everything that is in this post.

CQRS Myths

I do understand why people can be confused by CQRS as if you do a search, you’re bound to find blog posts that explain CQRS very differently. Some posts get it right, however a lot of others conflate CQRS with other concepts.

So which blog posts are right? Who has the correct definition? How do you even know what I’m writing is correct?

CQRS Definition

Greg Young, who coined the term, used to blog on CodeBetter.com and his own personal site, goodenoughsoftware.net.

Unfortunately, neither of those sites exist anymore. However thanks to archive.org, we can go back to a blog post that Greg wrote in 2010.

Example

Instead of having a single object that has both write & read operations, you would split that into two separate objects. For example:

CustomerService has methods that return state (read) and mutate state (write). In order apply CQRS, we simply need to split these up into separate objects that will do one or the other, but not both.

That’s it. CQRS applied.

So why the confusion?

I assume most of the confusion is because most examples showing CQRS are also showing a bunch of other things, which is where these myths come in.

There are so many blog posts that will show a diagram like the one above, that are applying CQRS, but also doing other things.

Myth #1: Multiple Databases

CQRS does not require you to have multiple databases. You can use the same database for writes (commands) as you can for reads (queries).

It’s not a physical separation but more of a logical one. If you’re using a relational database, you could create SQL Views that only your query side accesses.

Myth #2: Event Sourcing

Event Sourcing is the concept of storing immutable events derived from actions within your system that represent state change. Greg Young has been at the forefront of Event Sourcing, and since he coined the term CQRS, I can see how Event Sourcing often gets lumped into it.

Most often times if people are referring to both CQRS and Event Sourcing, they will use the label “CQRS/ES”. I think it’s a good idea as I hope it’s preventing more confusion.

You do not need to be Event Sourcing in order to be doing CQRS.

Myth #3: Asynchronous Messaging

You do not need to be using a message bus to apply CQRS. Commands do not need to be asynchronous. Everything can be done in a synchronous request/response manner.

I think this myth stems from people using a message bus along with Event Sourcing so they can create projects for a separate read model.

More

Greg wrote on his blog in 2012 common misconceptions that I don’t think if left us yet. Hopefully, this post shining a light on his original posts help clear things up.

Links

• CQRS without Multiple Data Sources
• Fat Controller CQRS Diet

The post CQRS Myths: 3 Most Common Misconceptions appeared first on CodeOpinion.

In my Fat Controller CQRS Diet series, I’ve shown the mediator pattern and the MediatR library. After a recent discussion with Reid Evans, he made me realize I haven’t really described the trade-offs.  This post is going to focus on trade-offs and an alternative to using the mediator pattern.

If you’re new to this series, here are earlier posts to get you up to speed:

1. Overview of Series
2. Simple Query
3. Simple Command
4. Command Pipeline
5. Notifications
6. Vertical Slices

Coupling

With the mediator pattern, communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

For me the purpose of using the mediator pattern is to limit the coupling between integration boundaries.  Those boundaries in my applications are typically the Web/UI Framework and my core application.

This means I’ll have my controllers take a dependency on the mediator and not my core application.

View the code on Gist.

Runtime Resolution

The downside to this that there is no compile time type checking.  When the mediator is invoked at runtime, it could fail to send the request if there is no handler defined.

In the code example above, if there is no IAsyncRequestHandler<Home, List<Album>> then an exception will be thrown on _mediator.SendAsync(new Home());

Coupling to Handler (or Interface)

We could get around this and get our type checking at compile time by having the request handler injected into our controller.

This is fairly reasonable since I often have one controller per command or query.  This then limits the dependencies I’d be putting into the constructor.

View the code on Gist.

Messaging

One aspect that I haven’t touched on (yet) in this series is about background processing and queues.  I really enjoy using Hangfire to create background jobs.   I’ve blogged about it before and how to integrate MediatR and Hangfire together.

The general approach I take is to use messaging between MediatR and Hangfire to keep it consistent on how commands or queries are made.  That means messaging with MediatR done in-process or done on out of process (on other machines) via Hangfire but routing them through MediatR.

Comments

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

Follow @codeopinion

The post Fat Controller CQRS Diet: Trade-offs appeared first on CodeOpinion.