Welcome to the AspNetCore-WebApi-CleanArchitecture wiki!

Clean Architecture

In a three layered architecture (User Interface; Business Logic; Data Access Layer) each layer has it's responsibility. The UI-Layer handles user requests and interacts with the business layer. The Business-Layer contains business logic to calculate/process/handle domain specific logic/use-cases and only interacts with the Data Access Layer. The DAL implements access to database/storage and provides related data via an interface.

Clean architecture/Onion architecture has an important advantage to traditional layered architecture. The compile-time dependency on layerd architecture strictly goes from UI -> BL -> DAL. This means, the business layer depends on the data access implementation. By using dependency inversion principle, you will end up in clean architecture (onion architecture). The business logic and domain model are put to the center of the application, whereas data access implementation (infrastructure) depends on the application core. To reach this, infrastructure and data access interfaces are defined in the application core, which are then implemented in the infrastructure layer.

Project structure:

CleanArchitecture.XxxModule.Core

The core project contains business domain rules, such as domain model (entities), enums, ... This project also contains interfaces, which are implemented in the infrastructure layer.

CleanArchitecture.XxxModule.Application

Here, business relevant implementations are done. (business logic)

• Use cases: implements specific use cases with CQRS-pattern
• Validations, Services

CleanArchitecture.XxxModule.Infrastructure

This project encapsulates access to infrastructure, such as SQL database, Storages, Services (Email, ...). Services and Repositories are implemented, wheras the interfaces are defined in the core project.

CleanArchitecture.Web.Api

Here the REST API controllers are implemented. The API is the only interface which is provided by the application to use from outside. The controllers uses the services/use cases which are implemented in the core project.

CleanArchitecture.Tests.Shared

Contains classes/types, which can be used in all other test projects (for example builder classes for entities)

CleanArchitecture.UnitTests

This project contains unit tests. Specially application core functionality is tested here.

CleanArchitecture.IntegrationTests

Integration tests are implemented here. Tests are written for infrastructure services/repositories with Entity Framework Core inmemory provider, azure storage emulator or real databases.

CleanArchitecture.FunctionalTests

The API, including authentication and middlewares is tested here. Http requests to the API are sent, to test the whole functionality (including infrastructure).

Project dependency diagram:

This diagram shows the project dependencies. As you can see, the domain and core project represents the application core, wheras the Web and Infrastructure projects depends on them.

REST API

See details to REST API on next page: REST API