Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
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.
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.
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.
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.
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.