Project Structure

Last Updated On December 01, 2021 😎

Here is how the .NET WebApi Boilerplate is structured.

fullstackhero’s .NET WebApi Boilerplate is based on Clean Architecture. In other words, Onion / Hexagonal Architecture. Read about the advantages and principles of Onion Architecture here →

General Structure

This means that the entire solution is built in such a way that it can be scaled, maintained easily by teams of developers. This WebAPI Solution Primarily consists of the following .csproj files.

├── src
│   ├── Host.csproj
│   ├── Core
│   |   ├── Application.csproj
│   |   └── Domain.csproj
|   ├── Infrastructure.csproj
|   ├── Migrators
│   |   ├── Migrators.MSSQL.csproj
│   |   ├── Migrators.MySQL.csproj
│   |   └── Migrators.PostgreSQL.csproj
│   └── Shared
│       └── Shared.DTOs.csproj

The idea is to build a very loosely coupled architecture following best practices and packages. Let’s see in brief what responsibilities each of these projects handle.

Host

Contains the API Controllers and Startup Logic including ASP.NET Core Container setup. This is the entry point of the application. Also, other static files like the logs, localization jsons, images, email templates and most importantly the appsettings.json live under this project.

With 0.0.5-rc, the appSettings.json is further split into variable sub-setting like database.json, security.json and so on for better modularity and organization. You can find these new JSONs under the Configurations folder of the Host project.

├── Host
|   ├── Configurations
|   ├── Controllers
|   ├── Email Templates
|   ├── Extensions
|   ├── Files
│   |   ├── Images
│   |   └── Documents
|   ├── Localization
|   ├── Logs
|   └── appsettings.json

Note that the Host project depends on

  • Application
  • Infrastructure
  • Migration Projects

Application

This is one of the projects in the Core Folder apart from the Domain Project. Here you get to see Abstract Classes and Interfaces that are inherited and implemented in the Infrastructure Project. This refers to Dependency Inversion.

├── Core
|   ├── Application
|   |   ├── Auditing
|   |   ├── Catalog
|   |   ├── Common
|   |   ├── Dashboard
|   |   ├── DependencyInjection
|   |   ├── Identity
|   |   ├── Multitenancy
|   |   ├── Settings
|   |   ├── Storage
|   |   └── Wrapper

The folders and split at the top level Feature-wise. Meaning, it now makes it easier for developers to understand the folder structure. Each of the feature folders like Catalog will have further sub-folders like

  • EventHandlers
  • Interfaces
  • Services
  • Validators

and so on. Thus everything related to a feature will be found directly under that Feature folder.

In cases where there are less number of classes / interfaces associated with a feature, all of these classes are put directly under the root of the feature folder. Only when the complexity of the feature increases, it is recommended to separate the classes by their type.

Note that the Application project does not depend on any other project.

Domain

Note that the Domain project does not depend on any other project.

As per Clean Architecture principles, the Core of this Solution i.e, Application and Domain projects do not depend on any other projects. This helps achieve Dependency Inversion (The ‘D’ Principle of ‘SOLID’).

Want to add in More Details or Update this Document ?

Edit this Document on GitHub

Like fullstackhero?

Support the project for the longer run!

Buy me a Coffee Sponsor