Category: CQRS

eShopOnContainers a Microservice based .NET Core Sample Application

Derek Comartin Leave a comment

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

eShopOnContainers

 

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.

Follow @CodeOpinion on Twitter

Software Architecture & Design

Get all my latest YouTube Vidoes and Blog Posts on Software Architecture & Design

Find MediatR Requests without Handlers

Derek Comartin 4 Comments

Find MediatR Requests with no HandlersYou’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

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

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.

 

Practical Microsoft Orleans

Derek Comartin 5 Comments

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.

Blog Post Series:

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.

Follow @CodeOpinion on Twitter