.NET Core Microservices – DShop

It’s been a while since I published the latest article, but it’s high time to finally get into the topic of microservices for real. Does open source, .NET Core, distributed system, Docker and other cool words sound good to you? If that’s the case, stick with me and let me guide you through the world (or at least part of it) of microservices. This is going to be the very first article (an introduction) of the upcoming series.



A few months ago, I had an idea to publish a detailed course about implementing microservices in .NET Core. It turned out, that a friend of mine, Darek, thought of a similar concept – so we teamed up, created the distributed application (available on GitHub) and gave a few lectures (close to 10) during IT events and conferences, here in Poland. The idea of the recording a video course is still there (and sooner or later, it will be published), yet for now, we need to polish some remaining bits of the application.

Nevertheless, whether you are a microservice expert or beginner, read a book published by Microsoft and studied the eShopOnContainers repository (or not), let me introduce you the DShop (Distributed Shop), a brand new solution, containing over 15 repositories, including API Gateway + 8 microservices written totally from the scratch using the latest version of ASP.NET Core (2.1.1), hopefully, a starting point for some of you, who wanted to get into the world of microservices hype but had no idea where to start, or got stuck somewhere during the journey.


As before mentioned, DShop stands for an acronym of Distributed Shop, simple as that.
Why another online shop? For a single reason – this domain is usually understood by all of the people (including developers) at least at its very basic level – products, shopping carts, orders etc. If you’re into the world of DDD, these are also pretty good bounded contexts, that can be treated as separate microservices. And trust me – we (Piotr and Darek, the core developers behind the project) made everything as simple as possible (besides some generic reflection magic and other quirks), so you should be able to understand quite fast what’s going on, simply by looking at the domain models or application services (handlers).


The whole idea behind DShop was to make it for you – the programmers, so that you can take a look at the code, play with it, validate your own ideas, copy our code and use it in your own projects, or point out our mistakes – whatever makes you a better software developers and provide the valuable content. Thus, you can download the whole source code from GitHub, just keep in mind that we update the repositories from time to time, fix bugs, refactor the code and extend some features – it’s an ongoing project.


One of our goals was to make the solution agnostic from cloud providers that offer some special services (e.g. Azure Service Bus or AWS Lambda). Basically, you can run DShop anywhere – on local machine, private server or in any cloud. Let’s have a glimpse, what technologies and tools are being used to make it work:

  • .NET Core – API Gateway and all microservices are written in C# and ASP.NET Core (2.1.1)
  • RabbitMQ – one of the most popular message buses out there and RawRabbit as client library
  • MongoDB – NoSQL databse to store the services data
  • Redis – extremely fast caching server, an ideal choice for distributed systems
  • Docker – containers are everywhere, so Dockerfile for each service and Docker compose on top of it
  • Travis CI – build service, free to use for open source projects hosted on GitHub
  • Docker Hub – Docker images repository, where DShop images are being published
  • Rancher – enterprise management for Kubernetes, open source and easy to use

There are of course some other tools or libraries being used e.g. Angular 6 for the web application (not finished yet), but let’s leave it for now, we’ll talk about them in the next posts.


Each project has its own repository. We’ll discuss the solution structure in the upcoming articles, but these are the most important projects (besides the bash scripts, that were simply copied from the base DNC-DShop repository).

DShop projects

DShop projects

In order to start DShop you need to have RabbitMQ, MongoDB, and Redis up and running (not to mention the latest version of .NET Core SDK). You can also easily start these through Docker – just take a look at the following script.

Once the required services are available, you can start either one by one or via Docker all of the microservices (projects named DShop.Services.Xyz, a total number of 8) and the API Gateway (DShop.Api). You can also make use of this script that loops through each repository and starts the project – just keep in mind to put that into the root directory, where the remaining projects are (as shown on the screen above).

Assuming that everything is up and running, you shall find the DShop.rest file that uses REST Client extension for the VS Code – give it a try and send a few HTTP requests to the API.

That being said, I encourage you to explore the source code and play with it. Stay tuned, as in the next posts we’ll go through the particular microservices implementation, talk about the distributed systems pros & cons and many, many other concepts that sometimes are not clearly visible at the first glance.

Oh, and finally – check out the DevMentors.io and subscribe to our social media channels, if you want to know once the video course will be completed.


If you know Polish, take a look at the following video that was recorded quite recently – here, we talk about the DShop and core aspects of microservices.

18 Comments .NET Core Microservices – DShop

  1. Pingback: .NET Core Microservices – DShop project - How to Code .NET

  2. Pingback: Dew Drop - July 5, 2018 (#2759) - Morning Dew

  3. tonymk

    Greate article! Looking forward to the continuation of the series. One request would be english subtitles on the video(s).

  4. Pingback: The Morning Brew - Chris Alcock » The Morning Brew #2621

  5. Karthick Thoppe

    Good one; the Devil is in the details, will take a look at the code. Is Polyglot aspect of the Microservices in your agenda for the future articles? Also, can anyone contribute to your DShop project or is it purely for demo purposes & showcase?


    1. Piotr Gankiewicz

      I used to implement services in different technologies, however, in DShop, we wanted to focus purely on .NET Core. Speaking of contribution – feel free to submit any PRs, just please keep in mind that eventually, we are going to record video course about it, thus we’d like to introduce rather small adjustments (at least for now) :).

  6. Radek Maziarka

    Thanks Piotrek for this great series of articles and repositories!

    I have a question regarding user authorization – how would you handle sharing user context between services? For example – we are removing user XYZ from Admin role by running an action in Identity service. How would other services know that this action took place?

    1. Piotr Gankiewicz

      Hi Radek, thanks!

      It really depends on what’s the end goal – if other services really have to be aware of such behavior, Identity Service could simply publish an event such as ‘UserRoleChanged’. Sharing user context – again, this can be done via ICorrelationContext (which contains UserId property) being a metadata type attached to all of the messages that are being published. Nevertheless, since the API is responsible for dispatching the actions properly and ensuring that user has required claims there’s rarely a need to share such information :).

  7. Pingback: .NET Core Microservices – theory, DShop solution structure | Piotr Gankiewicz

  8. Asad


    If you are going for micro service than each service should be a decouple components and should have its own UI as well . In your article there is no UI composition. If you modify your UI because a micro service changed than you need to test all of your UI which means you are testing all the micro services, second you are taking about gateway pattern, it means if you add and modify your micro service’s contract than you need to modify or deploy your gateway as well. You are not splitting monolithic application vertically and going for horizontally which I think is not a good approach.

    1. Piotr Gankiewicz

      I disagree, why would each microservice have its own UI? It doesn’t make much sense – you create a single API Gateway and then a special application on top of that (mobile, web, desktop) that communicates only with this API. Microservices should be kept internally.

  9. Pedro

    You guys rock! Thanks for your effort of writing sample microservices repository. Love from Manila Philippines.

  10. Nehmia

    This is just amazing. I have been looking for a complete distributed sample application using .NET Core, Angular 6, Docker and Kubernetes. I tried to go through the Polish video overview, eventhough I don’t understand Polish at all, just to see the architecture diagram. One thing I would like to ask is why it was needed to go through two handlers for create/update commands. From the video I saw that the Gateway ‘Create’ API publishes to Product Handler and then this handler published to Product Storage Handler to call repository to create the Product. Couldn’t the API directly publish to the Storage Handler by passing the Product Handler? Because for GET requests, we’re directly calling the Storage Service from the API. Just wanted clarification on this since I might have misunderstood the architecture.

    I can’t wait for the English version of this.

    Thank you!!


Leave A Comment

Your email address will not be published. Required fields are marked *