172 lines
6.1 KiB
Markdown
172 lines
6.1 KiB
Markdown
# Atlas Desk Architecture
|
|
|
|
Atlas Desk uses a modular monolith with a Vue frontend, ASP.NET Core API, and
|
|
PostgreSQL database.
|
|
|
|
## High-Level Overview
|
|
|
|
The system is deployed as one backend service and one frontend artifact. The
|
|
backend owns authentication integration, authorization, request workflows, audit
|
|
events, and persistence. The frontend renders queue workflows and calls the API.
|
|
|
|
```mermaid
|
|
flowchart LR
|
|
User["Support User"]
|
|
Browser["Vue SPA"]
|
|
API["ASP.NET Core API"]
|
|
Modules["Application Modules"]
|
|
Domain["Domain Model"]
|
|
Database["PostgreSQL"]
|
|
IdP["Identity Provider"]
|
|
|
|
User --> Browser
|
|
Browser --> API
|
|
API --> Modules
|
|
Modules --> Domain
|
|
Modules --> Database
|
|
API --> IdP
|
|
```
|
|
|
|
## Architecture Style
|
|
|
|
| Field | Value |
|
|
| --- | --- |
|
|
| Style | Modular monolith |
|
|
| Primary reason | Small team, shared database, evolving domain boundaries. |
|
|
| Main trade-off | Requires discipline to prevent module coupling. |
|
|
| Related decision | ADR-001 in `DECISIONS.example.md`. |
|
|
|
|
## Folder Structure
|
|
|
|
```text
|
|
atlas-desk/
|
|
backend/
|
|
src/
|
|
Requests/
|
|
Users/
|
|
Reporting/
|
|
Shared/
|
|
tests/
|
|
frontend/
|
|
src/
|
|
features/
|
|
shared/
|
|
tests/
|
|
docs/
|
|
```
|
|
|
|
| Folder | Responsibility |
|
|
| --- | --- |
|
|
| `backend/src/Requests` | Request lifecycle, assignment, notes, and closure. |
|
|
| `backend/src/Users` | User profile and role synchronization. |
|
|
| `backend/src/Reporting` | Queue health and manager dashboards. |
|
|
| `frontend/src/features` | User-facing feature modules. |
|
|
| `frontend/src/shared` | Reusable UI and API utilities. |
|
|
|
|
## Module Responsibilities
|
|
|
|
| Module | Responsibility | Owned Data | Public Interface |
|
|
| --- | --- | --- | --- |
|
|
| Requests | Support request workflow. | Requests, notes, assignments, audit events. | Request commands and query endpoints. |
|
|
| Users | Local user profile and role cache. | Users and role snapshots. | User lookup service. |
|
|
| Reporting | Aggregated queue health views. | Read models derived from requests. | Reporting queries. |
|
|
|
|
## Dependency Rules
|
|
|
|
- Feature modules may depend on `Shared`.
|
|
- `Reporting` reads request data through query interfaces, not direct mutation.
|
|
- Domain rules do not depend on HTTP, Vue, or database APIs.
|
|
- Infrastructure implementations depend inward on application contracts.
|
|
|
|
## Persistence Boundary
|
|
|
|
Atlas Desk uses the repository pattern for persistence boundaries.
|
|
|
|
- Repository interfaces live in the owning backend module.
|
|
- Repository implementations live in the module's infrastructure or persistence
|
|
folder.
|
|
- Repositories are domain-specific, such as `RequestRepository` and
|
|
`UserRepository`.
|
|
- Application services coordinate transactions for workflows that write multiple
|
|
records, such as assignment plus audit event creation.
|
|
- Generic CRUD repositories are not used because they hide workflow intent.
|
|
|
|
## Request Flow
|
|
|
|
```mermaid
|
|
sequenceDiagram
|
|
participant Browser
|
|
participant API
|
|
participant Auth
|
|
participant Requests
|
|
participant Database
|
|
|
|
Browser->>API: POST /api/requests/{id}/assign
|
|
API->>Auth: Check Manager or Agent policy
|
|
API->>Requests: AssignRequest command
|
|
Requests->>Database: Save assignment and audit event
|
|
Database-->>Requests: Commit result
|
|
Requests-->>API: Updated request summary
|
|
API-->>Browser: 200 OK
|
|
```
|
|
|
|
## Data Flow
|
|
|
|
| Data | Source | Owner | Storage | Consumers |
|
|
| --- | --- | --- | --- | --- |
|
|
| Support request | Agent or imported email | Requests module | PostgreSQL | Agents, managers, reporting. |
|
|
| User role | Identity provider | Users module | PostgreSQL role snapshot | Authorization policies. |
|
|
| Queue metrics | Request state changes | Reporting module | Materialized query table | Manager dashboard. |
|
|
|
|
## Domain Model
|
|
|
|
| Concept | Meaning | Invariants |
|
|
| --- | --- | --- |
|
|
| Request | A customer support item requiring work. | Must have status, priority, creator, and audit history. |
|
|
| Assignment | Ownership of a request by a user. | Only active users can own open requests. |
|
|
| Audit Event | Immutable record of important workflow action. | Cannot be edited after creation. |
|
|
|
|
## Integration Points
|
|
|
|
| Integration | Direction | Protocol | Reliability Expectations |
|
|
| --- | --- | --- | --- |
|
|
| Identity provider | Outbound | OpenID Connect | Login must fail closed if identity cannot be verified. |
|
|
| Email notifications | Outbound | SMTP or provider API | Retry transient failures; never block core assignment transaction. |
|
|
|
|
## Security
|
|
|
|
| Area | Policy |
|
|
| --- | --- |
|
|
| Authentication | All application routes require authenticated users. |
|
|
| Authorization | Backend policies enforce role and ownership checks. |
|
|
| Secrets | Secrets are environment-provided and never committed. |
|
|
| Input validation | API validates DTO shape before command execution. |
|
|
| Output encoding | Frontend renders user content safely through framework escaping. |
|
|
| Audit logging | Assignment, closure, and role changes create audit events. |
|
|
| Dependency security | CI runs dependency audit before release. |
|
|
|
|
## Error Handling
|
|
|
|
| Error Type | Handling Policy | User/Client Response |
|
|
| --- | --- | --- |
|
|
| Validation error | Return field-level errors. | 400 with validation details. |
|
|
| Domain error | Return stable problem code. | 409 or 422 with safe message. |
|
|
| Infrastructure error | Log with correlation ID and retry if safe. | 503 for transient failures. |
|
|
| Unexpected error | Log, alert if elevated, hide details. | 500 with correlation ID. |
|
|
|
|
## Performance
|
|
|
|
| Concern | Expectation | Measurement |
|
|
| --- | --- | --- |
|
|
| Latency | P95 below 300 ms for core endpoints. | API metrics. |
|
|
| Throughput | 100 concurrent active users. | Load test before production launch. |
|
|
| Resource usage | Single service fits standard container profile. | Runtime metrics. |
|
|
|
|
## Scalability
|
|
|
|
| Dimension | Current Strategy | Future Strategy |
|
|
| --- | --- | --- |
|
|
| Traffic | Single API service with horizontal scaling. | Split reporting read model if dashboards become expensive. |
|
|
| Data volume | PostgreSQL indexes for active queue queries. | Archive closed requests older than retention threshold. |
|
|
| Team size | Module ownership within one repo. | Extract services only after boundaries and ownership stabilize. |
|