Category: Architecture

Mediator between Integration Boundaries

Derek Comartin Leave a comment

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?

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.


How to get started with CQRS & Event Sourcing

Derek Comartin Leave a comment

hammernailWhen I first heard about CQRS & Event Sourcing concepts through various blogs and videos, primarily from Greg Young and Udi Dahan, I wanted to apply it everywhere.

It seems really natural to want to take the limited knowledge we have about a new concept or technology and try and apply it to any problem.

Most of us know this is a terrible idea, but we are so tempted to push the concepts on a problem that it just doesn’t fit.

I realize I’m grouping CQRS and Event Sourcing together in this post.  Generally, if you are applying Event Sourcing then you are doing CQRS.  The other way around isn’t always true.

The Problem

In the very beginning I had a difficult time seeing where CQRS and Event Sourcing were best applied.  Again, as a beginner with our new shiny new knowledge we have our blinders on.

We look at any new problem and try to make it fit what we think CQRS and Event Sourcing solves.

There are some pretty good examples scattered around the internet about different situations that CQRS and Event Sourcing have been applied.  You may be able to read these examples and get a better understanding about what the context and how it was a good fit.  Also, you may read horror stories about how it was a complete failure and why.

To be honest, I haven’t read that many horror stories as I assume people are too afraid to admit their failures, although it would be very helpful to the community.

Feeling the Pain

I could read all kinds of blogs about where not to apply CQRS & Event Sourcing, but I need to feel the pain first hand to really understand where it’s best used.

I needed to apply the concepts I read about in a meaningful project.

For me a meaningful project was a side-project I worked on after hours at home that was large enough in scale that wasn’t incredibly trivial.

The learning experience of failure (and success) gave me greater insights and a deeper understanding to the words I’ve previously read from others discussing CQRS & Event Sourcing.

Practice

Start using CQRS and Event Sourcing in a project that is meaningful to you.  Obviously, I’m not recommending it in a project at work.  Do it in on a project where you can fail.  Feel the pain of applying these concepts where they don’t provide enough value or are cumbersome (hint: CRUD).

With real practice, your understanding matures and not everything will look like a nail with your shiny new hammer.

Bounded Context and Subdomains

Derek Comartin 2 Comments

CarpetIn a previous blog, I discussed how I recently discovered through eventual consistency that I had poor business alignment.  With more thoughts and insights, I wanted to extend that post by discussion bounded contexts and how they fit within subdomains.

1 to 1?

I’ve often thought of a bounded context as being a one-to-one relationship with a subdomain.   To take that further, you may get the impression that they are indeed the same thing.  When I was first introduced to the concept many years ago, I was under the impression that they mapped directly one to one.

I’m not entirely sure why I had this perception early on.  It may be due examples or just the assumption I made.  I do not remember actually ever reading how a subdomain and a bounded context don’t map directly one to one.

Over the years I’ve realized this not to be the case, but always had a tough time giving an explanation that others could visualize.

I heard Eric Evans gave a great example that I will paraphrase, which should help you visualize the difference.

Living Room Floor

Imagine a room in your house.  It may have a closet or some different length walls which makes it not totally uniform.  Imagine there is carpet in this room.  The carpet covers every inch of the floor.  Wall to wall carpet.

This carpet represents your bounded context.

Underneath the carpet, say the cement, is your subdomain.

By Design

It just so happens that your bounded context is mapped to your subdomain exactly.  However, that is just because the bounded context (carpet) was designed that way.

A bounded context doesn’t necessarily need to cover the entire subdomain.  It only needs to cover the aspects of the subdomain which help solve the problem space.

To use the carpet analogy again, I mentioned that the room wasn’t completely uniform as maybe it had a closet in it.  The carpet doesn’t need to cover the entire floor beneath it.  There may be bare floor exposed in the closet because that portion of the subdomain doesn’t require to be modeled as it isn’t needed for problem you are trying to solve.

More Than One?

I’m still trying to determine if a subdomain can have more than one bounded context.  I do think it may be possible if you are implementing something technical apart of that subdomain.  I would love to hear others thoughts on this.