Keep your application code free of dependencies like persistence and presentation.

This repository provides several templates for creating .NET applications using the Clean Architecture pattern. The templates vary in complexity and include simple applications without data access layers, as well as more advanced applications with data access layers.

Clean Architecture is a software design pattern that separates the concerns of an application into layers, each with a specific responsibility. The pattern aims to make the application easier to maintain and test by reducing dependencies between the layers.

Using Clean Architecture has several benefits, including:

• Improved maintainability: The separation of concerns makes it easier to modify individual parts of the application without affecting the rest.
• Better testability: The layers can be tested independently, making it easier to write unit tests and integration tests.
• Easier to understand: The clear separation of concerns makes it easier for developers to understand the application's structure and flow.

These Clean Architecture templates use StartupOrchestration.NET to simplify the configuration and initialization of the application's dependencies and services.

When implementing Clean Architecture in an application, it's easy to have multiple ways to start the application. For example, the application can be started using any type of presentation layer, such as API, Console, or Azure Function. However, this can result in the same dependencies being registered in each startup sequence, which means the application may not behave consistently across different presentation layers.

To ensure the application always behaves the same, while allowing each presentation layer to register only the dependencies it needs, the StartupOrchestration.NET library provides a way to manage service registrations in a structured and consistent manner. This means that each presentation layer can register only the services it requires, while the application can register its own dependencies independently of the presentation layer. As a result, the presentation layer only needs to be responsible for registering its own required services, rather than managing all dependencies for the application.

Run the command:

dotnet new -i CleanArchitecture.Templates

• ca-sln - A simple application with three separate presentations
• ca-sln-sql - Includes an entity framework core implementation using Sql Server with Docker support

dotnet new ca-sln-sql --name MyNewApp --secure-port 44399 --port 34399

When you create a new project from one of the Clean Architecture templates, it will have a default RootNamespace and AssemblyName based on the template name. If you want to update these values to include your company name or a different namespace, follow these steps:

1. In Visual Studio, right-click on your project in the Solution Explorer and select "Properties".
2. In the properties window, click on the "Application" tab.
3. Update the "Assembly name" and "Default namespace" fields to the desired values.
4. Click "OK" to save the changes.

After updating the RootNamespace and AssemblyName, you will need to update any using statements in your code files that reference the old namespace. To do this, you can use Visual Studio's "Refactor" feature:

1. Right-click on the old namespace in your code file and select "Refactor" > "Rename".
2. In the rename dialog, enter the new namespace and click "Apply".
3. Visual Studio will update all the affected using statements and fully qualified type names in your code.

By updating the RootNamespace and AssemblyName, you can ensure that your project is properly named and organized for your company or personal use.

Clean Architecture is a highly effective software development approach that provides a clear separation of concerns and emphasizes the importance of scalability, testability, and maintainability. This article provides an in-depth explanation of Clean Architecture. If you want to learn more, I highly recommend reading Clean Architecture by Robert C. Martin.

Domain-Driven Design is an excellent choice for structuring solutions in conjunction with Clean Architecture, and it is well-suited for developing microservices. However, a monolithic application is still a viable solution for many problems.

MediatR is a third-party library that allows for clear separation of the presentation layer from the application layer. With MediatR, the controllers for an API or MVC presentation become much simpler, and it becomes easy to create custom functionality for maintenance or customer support tasks on the fly in a console application. For Azure Functions, you only need to decide which trigger you want to use.

AutoMapper is another useful tool that simplifies the translation of presentation models into the contract requirements for the application, domain, or persistence.

Take a deeper dive into the solution to understand the dependencies, assembly responsibilities, and organization setup.

Want to add a feature or fix a bug? Glad to have the help! There's just a couple of things to go over before you start submitting pull requests:

• Commit Message Standards

These templates are licensed under the MIT License.