Getting Started with Functional Programming in F#

Functional Programming in F#At last night’s Windsor-Essex .NET Developers Group, we had Reid Evans presenting a talk on Getting Started with Functional Programming in F#.

I absolutely loved this talk and wanted to share it along with some of my thoughts and takeaways.

I’ve been over the last year or two going back and forth with learning F# and understanding more functional programming concepts.  So I was really looking forward to this talk.


This is the live stream we had to our user group.  If you are interested in functional programming and F#, I highly recommend giving this a watch.



I thought Reid’s intended takeaways were all met.  I came out of that talk with exactly what he intended.  As a speaker, I think this is the ultimate goal.  What you are trying to convey is achieved.

That’s not to say people can find other takeaways, but knowing what you are trying to present and is received is great.

Defaults matter & No more null!

I think the hardest idea to fully “get” is how defaults matter.  I think this is really expressed when you see the difference of not being able to have null.

The alternative of using the Option Type (a Union Type) as an alternative way of thinking about the problem of something not existing.  In Reid’s example, a record not existing in the database.

What I love about is how you handle the resulting Option Type with pattern matching.  What I take from this is forcing the caller to property handle either Some or None.

I think Reid said it really well that if your language allows null, you must check for null everywhere.  If it does not allow null, and uses something like an Option type, then that is very explicit.

Type Providers == Awesome

They are truly awesome.  It was really interesting to see how a type from a column of a database could be then be used to infer the argument of a method.  This is kind of mind blowing.

I can see the value this would provide a developer in terms of not making simple accidental mistakes.  Plus having a built in integration test at compile time is just fantastic.

Composing Small Functions

Although the idea of writing small classes and methods are familiar to you in C#, I think the concept of you use those functions in a functional language is what differs.

I loved the example of how the validation was tied together as it gives a great real world example.  As with everything I still need more understanding on this and where this can take you.

Other Thoughts

What I loved about this talk is it used real world simple examples of things you would do building an app like data access and validation.

It was very easy to transfer the content into something you could relate to.  I think the fact that Reid often went down the road of making the comparisons to something I was already familiar with was a great help.

If you watched the video, I’d love to hear your comments.   Reid would probably love feedback as well.  Please post a comments or on Twitter.

Developing Features not Layers

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.


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.



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.


Features not Layers

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.


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.

MicroBus: In-Process Mediator

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.


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.


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.

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.

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.


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


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.