This is a template API using Clean Architecture alongside a .net implementation of GraphQL.
This solution in built on the .net 6 SDK, you need to install that before it will work for you. If you want to build the Dockerfile you will need to install Docker as well.
This is a template and you can install it using the dotnet new cli. To install the lastest version of the template run the following command.
dotnet new --install CleanGraphQLApi.TemplateTo create a new solution using this template run the following command
dotnet new cleangraphqlapi --name {YOUR_SOLUTION_NAMESPACE} --au "{YOU_AUTHORS_NAME}"There's a dockerfile included in the build folder and serves the purpose of restoring, building, testing, publishing and then creating a runtime image of the API. Works on my machine.....you can add a version prefix and suffix to version the service in the assembly. The Dockerfile does have stages so you can just run the tests or publish the solution depending on your needs. Review the build-pipeline.yml in the github folder for more detailed usage.
docker build . -t cleangraphqlapi:latest --build-arg VERSION_PREFIX {VERSION_NUMBER} -- build-arg VERSION_SUFFIX {PRERELEASE_NAME}The Github Action does publish an image of this API and you check it out for yourself by runnning this command in docker.
docker pull stphnwlsh/cleangraphqlapiThis solution is loosly based on Clean Architecture patterns, it's by no means perfect. I prefer to call it "Lean Mean Clean Architecture". Inspiration has been taken from Jason Taylor's Clean Architecture Template, but I have made some structural decisions to take some things further and scaled back others.
There's a little CQRS type stuff going on here but it's more in style than real separated functions for reading and writing as under the covers they are the same data source.
Breaking the Clean Architecture pattern is the fact that the Infrastructure project is referenced by the Presentation project. This is for Dependency Injection purposes, so to protect this a little further, all classes in the Infrastructure project are internal. This stops them being accidentally used in the Presentation project.
It's streamlined into 3 functional projects. All serve their own purpse and segregate aspects of the application to allow easier replacement and updating.
- Presentation - Setting up the interactions between the Application layer and the consumer. In the project that's via a Web API but it could be many other things. The Web API uses controllers to funnel the actions to the layer that owns the domain.
- Application - This project owns the domain and business logic. There's validation of the Commands and Queries and handling of domain entities in their own separated structures. Each domain type has it's own interface to a datasource downstream, this project doesn't care what fulfills this contract, as long as someone does.
- Infrastructure - Here's where the database comes into play. Infra owns the data objects and works with the repository interfaces to fetch, create, update and remove object from the source. There's some entity mapping here to allow specific models with attributes to remain in this layer and not bleed through to the Application layer.
There are plenty of handy implementations of features throughout this solution, in no particular order here are some that might interest you.
- Logging using Serilog
- Mediator Pattern using Mediatr
- Validation using FluentValidation
- Testing using Shouldly and NSubstitute
- GraphQL using GraphQL for .NET
This sample would not have been possible without gaining inspiration from the following resources. If you are on your own learning adventure please read the following blogs and documentation.
If you like this, or want to checkout my other work, please connect with me on LinkedIn, Twitter or GitHub, and consider supporting me at [Buy Me a Coffee].
