适用于 .NET 应用程序的终极清晰架构模板
dotnet new install Amantinband.CleanArchitecture.Template
dotnet new clean-arch -o CleanArchitecture
This template is still under construction .
Check out my comprehensive course on Dometrain where I cover everything you need to know when building production applications structured following clean architecture. Use the exclusive coupon code GITHUB to get 5% off (btw this is the only promo code for a discount on the bundle, which is already 20% off).
Loving it? Show your support by giving this project a star!
This is a simple reminder application. It allows users to create and manage their reminders.
To create reminders, a user must have an active subscription.
Users with a basic subscription can create up to 3 daily reminders.
Users with a pro subscription do not have a daily limit on the number of reminders.
dotnet new install Amantinband.CleanArchitecture.Template
dotnet new clean-arch -o CleanArchitecture
or
git clone https://github.com/amantinband/clean-architecture
docker compose up
or
dotnet run --project src/CleanArchitecture.Api
Navigate to requests/Tokens/GenerateToken.http and generate a token.
Note: Since most systems use an external identity provider, this project uses a simple token generator endpoint that generates a token based on the details you provide. This is a simple way to generate a token for testing purposes and is closer to how your system will likely be designed when using an external identity provider.
POST {{host}}/tokens/generate
Content-Type: application/json
{
"Id": "bae93bf5-9e3c-47b3-aace-3034653b6bb2",
"FirstName": "Amichai",
"LastName": "Mantinband",
"Email": "[email protected]",
"Permissions": [
"set:reminder",
"get:reminder",
"dismiss:reminder",
"delete:reminder",
"create:subscription",
"delete:subscription",
"get:subscription"
],
"Roles": [
"Admin"
]
}
NOTE: Replacing http file variables (
{{variableName}})Option 1 (recommended) - Using the REST Client extension for VS Code
Use the REST Client extension for VS Code + update the values under .vscode/settings.json. This will update the value for all http files.
…
Options 2 - Defining the variables in the http file itself
Define the variables in the http file itself. This will only update the value for the current http file.
@host = http://localhost:5001 POST {{host}}/tokens/generateOption 3 - Manually
Replace the variables manually.
POST {{host}}/tokens/generatePOST http://localhost:5001/tokens/generate
POST {{host}}/users/{{userId}}/subscriptions
Content-Type: application/json
Authorization: Bearer {{token}}
{
"SubscriptionType": "Basic"
}
POST {{host}}/users/{{userId}}/subscriptions/{{subscriptionId}}/reminders
Content-Type: application/json
Authorization: Bearer {{token}}
{
"text": "let's do it",
"dateTime": "2025-2-26"
}
You can use the this figma community file to explore or create your own folder structure respresentation.
This project puts an emphasis on complex authorization scenarios and supports role-based, permission-based and policy-based authorization.
To apply role based authorization, use the Authorize attribute with the Roles parameter and implement the IAuthorizeableRequest interface.
For example:
[Authorize(Roles = "Admin")]
public record CancelSubscriptionCommand(Guid UserId, Guid SubscriptionId) : IAuthorizeableRequest<ErrorOr<Success>>;
Will only allow users with the Admin role to cancel subscriptions.
To apply permission based authorization, use the Authorize attribute with the Permissions parameter and implement the IAuthorizeableRequest interface.
For example:
[Authorize(Permissions = "get:reminder")]
public record GetReminderQuery(Guid UserId, Guid SubscriptionId, Guid ReminderId) : IAuthorizeableRequest<ErrorOr<Reminder>>;
Will only allow users with the get:reminder permission to get a subscription.
To apply policy based authorization, use the Authorize attribute with the Policy parameter and implement the IAuthorizeableRequest interface.
For example:
[Authorize(Policies = "SelfOrAdmin")]
public record GetReminderQuery(Guid UserId, Guid SubscriptionId, Guid ReminderId) : IAuthorizeableRequest<ErrorOr<Reminder>>;
Will only allow users who pass the SelfOrAdmin policy to get a subscription.
Each policy is implemented as a simple method in the PolicyEnforcer class.
The policy "SelfOrAdmin" for example, can be implemented as follows:
…
You can mix and match authorization types to create complex authorization scenarios.
For example:
[Authorize(Permissions = "get:reminder,list:reminder", Policies = "SelfOrAdmin", Roles = "ReminderManager")]
public record ListRemindersQuery(Guid UserId, Guid SubscriptionId, Guid ReminderId) : IAuthorizeableRequest<ErrorOr<Reminder>>;
Will only allow users with the get:reminder and list:reminder permission, and who pass the SelfOrAdmin policy, and who have the ReminderManager role to list reminders.
Another option, is specifying the Authorize attribute multiple times:
[Authorize(Permissions = "get:reminder")]
[Authorize(Permissions = "list:reminder")]
[Authorize(Policies = "SelfOrAdmin")]
[Authorize(Roles = "ReminderManager")]
public record ListRemindersQuery(Guid UserId, Guid SubscriptionId, Guid ReminderId) : IAuthorizeableRequest<ErrorOr<Reminder>>;
This project puts an emphasis on testability and comes with a comprehensive test suite.
The domain layer is tested using unit tests. By the bare minimum, each domain entity should have a test that verifies its invariants.
The application layer is tested using both unit tests and subcutaneous tests.
Since each one of the application layer use cases has its corresponding subcutaneous tests, the unit tests are used to test the application layer standalone components, such as the ValidationBehavior and the AuthorizationBehavior.
Subcutaneous tests are tests that operate right under the presentation layer. These tests are responsible for testing the core logic of our application, which is the application layer and the domain layer.
The reason there are so many of these tests, is because each one of the application layer use cases has its corresponding subcutaneous tests.
This allows us to test the application layer and the domain layer based on the actual expected usage, giving us the confidence that our application works as expected and that the system cannot be manipulated in a way we don't allow.
I recommend spending more effort on these tests than the other tests, since they aren't too expensive to write, and the value they provide is huge.
The api layer is tested using integration tests. This is where we want to cover the entire system, including the database, external dependencies and the presentation layer.
Unlike the subcutaneous tests, the focus of these tests is to ensure the integration between the various components of our system and other systems.
Note: Eventual consistency and the domain events pattern add a layer of complexity. If you don't need it, don't use it. If you need it, make sure your system is designed properly and that you have the right tools to manage failures.
The domain is designed so each use case which manipulates data, updates a single domain object in a single transaction.
For example, when a user cancels a subscription, the only change that happens atomically is the subscription is marked as canceled:
public ErrorOr<Success> CancelSubscription(Guid subscriptionId)
{
if (subscriptionId != Subscription.Id)
{
return Error.NotFound("Subscription not found");
}
Subscription = Subscription.Canceled;
_domainEvents.Add(new SubscriptionCanceledEvent(this, subscriptionId));
return Result.Success;
}
Then, in an eventual consistency manner, the system will update all the relevant data. Which includes:
暂无开放 Issues，或尚未同步最近议题。