Files
AgileConfig/docs/application-layer.md
2026-08-24 00:57:44 +08:00

51 lines
1.8 KiB
Markdown

# Application layer
`AgileConfig.Server.Application` contains transport-independent application use cases. Both the legacy MVC controllers and the REST API controllers call this layer so that business behavior is implemented once.
## Dependency direction
```text
Apisite controllers
|
v
AgileConfig.Server.Application
|
v
AgileConfig.Server.IService / domain events
|
v
repositories
```
The Application project must not reference ASP.NET Core MVC, Apisite request models, controllers, or HTTP result types.
## Responsibilities
Controllers own:
- authentication and authorization filters;
- HTTP request and response models;
- status codes, headers, routes, and `ProblemDetails`;
- compatibility mapping for legacy response envelopes.
Application services own:
- use-case validation and conflict detection;
- entity creation and state transitions;
- orchestration of the existing business services;
- current-user audit values and timestamps;
- domain-event publication and other required side effects.
The existing services in `AgileConfig.Server.IService` and `AgileConfig.Server.Service` continue to own persistence-oriented operations, queries, caches, and lower-level domain behavior.
Expected business failures are returned as `ApplicationResult` values. Application services do not return `IActionResult`, select HTTP status codes, or format user-facing HTTP payloads.
## Compatibility
Legacy and v2 controllers deliberately map the same application result differently:
- legacy controllers preserve their existing `{ success, message, data }` envelopes and status-code behavior;
- v2 controllers use resource responses, standard status codes, and `ProblemDetails`.
Any application-service migration must keep integration coverage for both contracts.