REST API solution demonstrates how to create clean and modern API with Clean Architecture, minimal API and various of design patterns.
Example API allows to upload/download files with .txt, .json, .csv, .xml, .yml extensions and get collection of uploaded files. Also allow to convert between json, xml, yml formats.
Simply Run File.API and try it. Or in case You need to edit Content Type, use Postman. Example gif of how to change ContentType in Postman.
Main motivation is to write practical example of minimal API with Clean Architecture and experiment with libraries for validation and mapping.
Projects folows Clean Architecture, but application layer is splitted to Core and Domain projects where Core project holds business rules and Domain project contains business entities.
As Minimal API allows to inject handlers into endpoint map methods, I decided to do not use MediatR, but still every endpoint has its own request and handler. Solution folows CQRS pattern, it means that handlers are separated by commands and queries, command handlers handle command requests and query handlers handle query requests. Also repositories (Repository pattern) are separated by command and queries.
Instead of throwing exceptions, project use Result pattern (using FluentResuls package) and for returning exact http response, every handler returns data wraped into HttpDataResponse object which contains also error messages collection and http response code.
Important part of every project are tests. When writing tests we want to achieve optimal code coverage. I think that every project has its own optimal code coverage number by it's need and I always follow the rule: cover your code to be able refactor without worry about functionality change.
In this solution, each 'code' project has its own unit test project and every unit test project copy the same directory structure as 'code' project, which is very helpful for orientation in test project. Infrastructure project has also integration tests, because for format conversion is used third party library and we want to know that conversion works always as expected (for example when we update library version).
Solution contains four layers:
- File.API - entry point of the application, top layer
- Endpoints
- Middlewares (or Filters)
- API Configuration
- File.Infrastructure - layer for communication with external resources like database, cache, web service..
- Repositories Implementation - access to database
- External Services Proxies - proxy classes implementation - to obtain data from external web services
- Infastructure Specific Services - services which are needed to interact with external libraries and frameworks
- File.Core - business logic of the application
- Request Handlers/Managers/.. - business implementation
- Abstractions - besides abstractions for business logic are there abstractions for Infrastructure layer (Service, Repository, ..) to be able use them in this (core) layer
- File.Domain - all what should be shared across all projects
- DTOs
- General Extensions
