MyWarehouse

MyWarehouse – A Clean Architecture, Vertical Slicing, DDD sample in ASP.NET Core

<br/>

This is a sample project consisting of an ASP.NET Core web API backend service and an Angular frontend with Bootstrap.

I have finally decided it's time to have something public on my GitHub account that is actually relevant to my professional focus on ASP.NET Core, retiring those god-awfully written old classical ASP.NET projects I had on BitBucket.

The following, rather informatively written documentation page has a two-fold purpose:

1. To be – hopefully – useful for others who wish to explore a similar direction in development.
2. To provide a summary of my current approach to working with ASP.NET Core, and my current level of understanding thereof, so anyone who was interested in my skillset could easily review it in a single place.

Live Demo

See here. You'll have to sign in with the credentials shown on the picture below, or with your Google account*. The backend is hosted in an Azure App Service, connecting to an Azure SQL database. The frontend is hosted right here, at the excellent GitHub Pages. Apologies if the first request times out – Azure is spinning the services down if there is no traffic.

Feel free to alter the data, as the solution has an automatic sample generation module that I can run any time to reset it. What it doesn't have is a profanity filter. But I trust your maturity. 😅

With respect to deployment, the backend and the frontend are both automatically deployed by the corresponding GitHub CD pipeline when a push happens in the master branch. So the build you see should always reflect the state of the master branch.

*Google login privacy concerns: The app doesn't store any personally identifying data. The only data of yours that can end up being saved in database is your name (as LastModifiedBy) when you modify an entity. But no email address or Google profile ID is saved.

<p align="center"> <a href="https://baratgabor.github.io/MyWarehouse" target="_blank"><img src=".github\demo-button.png" width="500" /></a> </p>

Screenshots

<p align="center"> <a href="https://raw.githubusercontent.com/baratgabor/MyWarehouse/master/.github/screenshots/1.png" target="_blank"><img src=".github\screenshots\1.png" height="250"/></a> <a href="https://raw.githubusercontent.com/baratgabor/MyWarehouse/master/.github/screenshots/2.png" target="_blank"><img src=".github\screenshots\2.png" height="250"/></a> <a href="https://raw.githubusercontent.com/baratgabor/MyWarehouse/master/.github/screenshots/3.png" target="_blank"><img src=".github\screenshots\3.png" height="250"/></a> </p>

---

Contents:

• Technologies
• Backend Design Paradigms
  • Clean Architecture
  • Vertical Slicing
  • Domain Driven Design
• Project structure
• Diversions from and extensions to the Clean Architecture Template
  • DDD in Domain
  • Paging, ordering and filtering
  • Infrastructure layer modularization
  • Improved integration/unit testing
  • Support structure for strongly typed configuration
  • API versioning
  • Repository layer
  • Logging extensions
  • No Identity Server integration
  • Deemphasizing CQRS
  • .Net 5 (C# 9) features
  • More feature-rich Angular frontend
• Potential improvements
• How to set up to run locally
• .NET 6.0 update improvements

Motivation

This experimental/sample project is the product of my experiences and pains with traditional n-tier, anemic model, file type folder based ASP.NET Web APIs. The ones where you have a Controllers, Models, Services top-level segregation, sometimes as separate assemblies, and your models are essentially simple DTOs, massaged by countless "services", "handlers", "managers", "validators", etc. All of which lead to a code base which is relatively hard to navigate, hard to reason about what touches what, brittle, and generally prone to bugs.

Also, oh my, the Startup.cs madness, where you just put everything in, and a few months later you have a monster Startup where you have no idea anymore what is required for what, and it often feels anything you touch breaks something else.

I'm not saying I never want to work on a more classical project, since there are realities we have to cope with, but I wanted to push my skillset and understanding into a new direction.

Origin/disclaimer:

This project had an older version I originally developed for a job application, with functionality they specifically asked to implement. I actually know very little of warehouses as a business domain, and I have no contact with any business experts from this domain, so the domain aspect (perhaps confusingly) is not intended to model a real warehouse. What I explored doing, with respect to the domain, is introducing validation and logic in entities, locking them down by not exposing mutable properties, and using value objects like Money and Mass (instead of primitive obsession) in the context of EF Core (i.e. owned types).

Technologies

C# 10 ◊ .NET 6 ◊ ASP.NET Core 6 ◊ Entity Framework Core 5 ◊ Angular 11 ◊ Bootstrap ◊ MediatR ◊ AutoMapper ◊ FluentValidation ◊ NUnit ◊ Moq ◊ FluentAssertions ◊ Respawn ◊ Swagger

Backend Design Paradigms

The backend system uses the following design paradigms (besides the fundamentals not worth mentioning). You can find plenty of dry materials pertaining to these subjects, so I mostly focused on providing a pragmatic narration that could perhaps help you to 'get the point' if you had difficulties extracting that value from other sources.

Clean Architecture

Uncle Bob's Clean Architecture is one of the most well-known modern architectural paradigms, which focuses on creating an application core that is devoid of infrastructural implementation concerns, pushing those out to an infrastructure layer (including the persistence mechanism, which is quite famously argued to be just a 'detail').

Similarly to the onion architecture, the dependencies between layers are strictly pointing inwards, so you end up with a domain and application layer that is self-contained and decoupled from higher level, less stable components of the system. Application layer dependencies are declared locally as interfaces, implemented by concrete services in the infrastructure layer. This is in contrast to the classical n-tier design where you have horizontal layers on top of a database communication layer, often tightly coupling the business logic to infrastructural and external concerns, arguably leading to maintenance headaches down the road.

The basis of my project structure comes from Jason Taylor's excellent Clean Architecture template, inspired by his relevant conference talk. But, even though this is still just a small sample project, I vastly expanded on that template, implementing many structurally significant decisions; the most significant being the integration of DDD concerns in the Domain.

Vertical Slicing

Vertical slicing is the concept and technique of structuring your solution into more-or-less self-contained feature slices instead of using a bunch of generalized services from layers upon layers.

The inspiration comes from the experience of brittleness that a highly service-oriented architecture can exhibit. E.g. when you try to implement a new feature or modify an existing, so you change the service it depends on, only to realize that you broke another feature that depended on the same service, because you didn't take into account all use cases of the given service component. Then you go and fix it,