This project is an experiment trying to create a solution template with Minimal APIs and Carter.

• API

  • Minimal API with .NET 6 and Carter
  • Vertical Slice Architecture
  • CQRS with MediatR
  • FluentValidation
  • AutoMapper
  • Entity Framework Core 6
  • Swagger with Code generation using NSwag
  • Logging with Serilog
  • Decorator pattern using PipelineBehaviors

• Testing

  • NUnit
  • FluentAssertions
  • Respawn

• Angular

  • HttpClient generated with NSwag and OpenAPI definition
  • Simple CRUD

• Blazor

  • HttpClient generated with NSwag and OpenAPI definition
  • Simple CRUD

• Separation of concerns
• Encapsulation
• Explicit dependencies
• Single responsibility
• Persistence ignorance*

The easiest way to get started is using Visual Studio 2022 or installing the .NET 6 SDK with dotnet run.

To create a new migration with dotnet-ef you first need to locate your API folder and then write the following:

dotnet ef migrations add <MigrationName> --project ..\Application\ -o Infrastructure\Persistence\Migrations

Aldo, you need to update the database:

dotnet ef database update

This project is an experiment trying to create a solution for Minimal APIs using Vertical Slice Architecture.

If you think this is highly coupled, the important thing is to minimize coupling between slices, and maximize coupling in a slice; if you need to change something (e.g. switching Entity Framework for Dapper), you only need to change the affected slices and not a big file with all of the data access.

If you want to learn more, the project is based on these resources:

• Choosing between using clean or vertical
• Restructuring to a Vertical Slice Architecture
• Vertical Slice Architecture - Jimmy Bogard

Minimal API that only hosts the application and wires up all the dependencies

This project contains all the core and infrastructure of the application. The intention is to separate the application by functionality instead of technical concerns.

This will contain all entities, enums, exceptions, interfaces, types, and logic specific to the domain layer (this layer is shared between all features).

We can have domain events, enterprise logic, value objects, etc. This layer (or folder in this project) has the same purpose according with DDD.

This layer contains classes for accessing external resources. These classes should be based on interfaces only if we need them for testing. For example, Entity Framework is testable, and repositories are not needed. But if external services are called, we should abstract these classes for easy testing.

This folder contains all the "slices" of functionality, and each slice does not overlap with other slices. If you need to change something, you only change a portion of a slice or, if new features are needed, you add code in new files which saves you from modifying large files (like repositories or services).

Inspired by:

• ContosoUniversityDotNetCore-Pages by Jimmy Bogard
• CleanArchitecture by Jason Taylor
• Carter by Carter Community