This is a starting point (TEMPLATE) for Clean Architecture with .NET 8. Clean Architecture is just the latest in a series of names for the same loosely-coupled, dependency-inverted architecture. You will also find it named hexagonal, ports-and-adapters, or onion architecture.

This project AmberEggApi cover concepts about:

• CQRS
• Dependency Injection
• Loose Coupling
• SOLID Principles

• .NET 8.0

• Autofac
• AutoMapper
• FluentAssertions
• NUnit
• Swagger

• Entity Framework + InMemory + Data Migration

• Visual Studio Code
• GIT Bash
• GitHub(Repos, Actions)
• MSSQL Server Management Studio
• Swagger Editor

cd\
mkdir repo
cd repo
git clone https://github.com/diegosmorf/AmberEggApi.git

powershell .\clone-to-your-namespace.ps1 "Your.Namespace"
cd ..\Your.Namespace

dotnet restore
dotnet build
dotnet test
dotnet run --p AmberEggApi.WebApi

you can access this API via browser: http://localhost:5200/swagger

Api.Common.CQRS.Core is a basic set of interfaces for building a command and event driven CQRS application.

• Commands are created and dispatched by the application,
• They are received by command handlers which apply behaviors on the domain model
• Which generates events
• Collected by the command handler
• Then published
• Received by event handlers which update the read/query model
• Consumed by the front end of the application via query services.

Domain commands and handlers specifically affect the domain model's aggregate roots.

Some of the basic premises of CQRS are modeled by these interfaces either explicitly or in their documentation.

• Commands and events should be immutable
• The query model should be immutable, except from the event handlers responsible for updating them when triggered by events published from domain model changes
• Domain commands and handlers should only affect a single aggregate root instance in the domain model - more complex operations should be handled by sagas

This project will expose domain features to external world (e.g.: API, Apps, Windows Services, Desktop apps) and it is responsible for business rules as well.

This project contains implementations of the interfaces defined in the inner layers of the solution. They may be dependent on external libraries or resources. Note that the implementations themselves are internal and should only be used for injection via their implemented interfaces.

API project exposing business controllers.

DomainTest: NUnit will test ApplicationService classes with no external dependencies. All Infrastructure dependencies must be mocked.

IntegrationTests:Longer running, more involved tests that test the integration of multiple components and external dependencies as Database/Email.

• Binaries committed to source control.
• Unnecessary project or library references or third party frameworks.
• Many "try" blocks - code defensively and throw exceptions if something is wrong.
• Third party APIs exposed via public interfaces.