docs: add layer readmes for architecture boundaries

This commit is contained in:
2026-10-09 23:06:49 +02:00
parent ed06e460c3
commit 4fa57efca4
4 changed files with 155 additions and 0 deletions

View File

@@ -0,0 +1,41 @@
# DigitalData.TaskFlow.Application
Dieses Projekt enthaelt die Use-Case-Schicht der Anwendung.
## Zweck
Die Application-Schicht orchestriert fachliche Anwendungsfaelle. Sie nimmt Requests entgegen, validiert diese, ruft Domain-nahe Abstraktionen auf und liefert strukturierte Ergebnisse zurueck.
## Aktueller Inhalt
- `DependencyInjection.cs`
- Registriert zentrale Application-Dienste:
- MediatR
- FluentValidation
- AutoMapper
- Bindet `MediatR`-Optionen inklusive Lizenzschluessel.
- `Options/`
- `MediatROptions`: Konfiguration fuer MediatR (z. B. `LuckyPennySoftLicenseKey`).
## Geplante Inhalte (naechste Phasen)
- `Features/`
- Queries/Commands fuer Workflows, Closing und Documents.
- `Validators/`
- FluentValidation-Regeln pro Request.
- `Common/Behaviors/`
- Pipeline-Behavior (z. B. zentrale Request-Validierung).
- `Common/Interfaces/`
- Repository-Abstraktionen fuer Datenzugriff.
- `Mappings/`
- AutoMapper-Profile zwischen Infrastrukturmodellen und Domainmodellen.
## Architektur-Regeln
- Keine direkten SQL- oder EF-Core-Aufrufe.
- Keine HTTP-spezifischen Controller-Abhaengigkeiten.
- Kommunikation nach aussen nur ueber Interfaces.
## Rolle im Gesamtsystem
Diese Schicht ist der zentrale Ausfuehrungspunkt fuer Use-Cases und verbindet die API-Schicht mit Domain und Infrastructure, ohne Technologie-Details nach oben durchzureichen.

View File

@@ -0,0 +1,33 @@
# DigitalData.TaskFlow.Domain
Dieses Projekt bildet den fachlichen Kern von `DigitalData.TaskFlow`.
## Zweck
Die Domain-Schicht enthaelt ausschließlich fachliche Modelle und Begriffe. Hier wird beschrieben, **was** das System fachlich darstellt, nicht **wie** Daten gelesen/geschrieben werden.
## Aktueller Inhalt
- `Common/`
- `ApiEnvelope<T>`: Standard-Response-Huelle mit `Meta` und `Data`.
- `MetaEntry`: Einzelner Meta-Eintrag (`Code`, `Message`).
- `Enums/`
- `MetaCode`: Fachliche Status-Codes (z. B. `Ok`, `NoAccess`, `AlreadyClosed`).
- `Workflows/`
- Modelle fuer den Endpoint `GET /workflows/{wisagid}`.
- Enthalten Quellblock-Struktur (`SourceBlock`, `FerdinandSourceBlock`, `ContractsSourceBlock`) und Untermodelle (`ProfileItem`, `WorkflowListingItem`, `ApprovalItem`, `DocumentReferenceItem`, `ClosingMethodItem`, `RejectionReasonItem`).
- `Closing/`
- Modelle fuer den Endpoint `POST /workflows/{wisagid}/{source}/{processid}/closing`.
- `CloseWorkflowDecision` (Eingabe), `CloseWorkflowResult` (Ergebnis).
- `Documents/`
- `DocumentBinaryResult` fuer den Endpoint `GET /documents/{id}`.
## Architektur-Regeln
- Keine EF-Core-, HTTP-, SQL- oder Infrastruktur-Abhaengigkeiten.
- Keine Controller- oder Middleware-Logik.
- Modelle bleiben in PascalCase; technische DB-Namensabweichungen werden spaeter in Infrastructure gemappt.
## Warum diese Schicht wichtig ist
Die Domain stellt eine stabile, technologieunabhaengige Sprache bereit. Dadurch koennen API, Application und Infrastructure getrennt entwickelt werden, ohne den fachlichen Vertrag zu verlieren.

View File

@@ -0,0 +1,37 @@
# DigitalData.TaskFlow.Infrastructure
Dieses Projekt implementiert technische Integrationen der Anwendung.
## Zweck
Die Infrastructure-Schicht setzt die in Application definierten Abstraktionen konkret um. Dazu gehoeren Datenbankzugriffe (EF Core, Stored Procedures) und spaeter ggf. DMS- oder externe Service-Anbindungen.
## Aktueller Inhalt
- `DependencyInjection.cs`
- Einstiegspunkt fuer die Registrierung technischer Dienste.
- `Options/`
- Platz fuer Infrastruktur-spezifische Optionen (falls benoetigt).
## Geplante Inhalte (naechste Phasen)
- `Persistence/`
- `TaskFlowDbContext` mit SQL-Server-Konfiguration.
- Entity-Konfigurationen inklusive Feld-Mapping (DB-Namen -> PascalCase-Modelle).
- `Repositories/`
- Implementierungen fuer:
- Workflow-Lesezugriff (u. a. `PRCUST_F19_GET_LISTING_DATA`)
- Workflow-Closing (Write-Procedure)
- Dokument-Binary-Zugriff
- `Persistence/Models/`
- Keyless Modelle fuer Procedure-Ergebnisse.
## Architektur-Regeln
- Keine Controller- oder HTTP-Logik.
- Keine fachliche Regel-Definition; nur technische Umsetzung.
- SQL-Zugriff stets parameterisiert und sicher.
## Rolle im Gesamtsystem
Infrastructure kapselt alle externen Abhaengigkeiten. Dadurch bleibt die Application-Schicht testbar und von Technologie-Details entkoppelt.

View File

@@ -0,0 +1,44 @@
# DigitalData.TaskFlow.API
Dieses Projekt stellt die HTTP-Schnittstelle fuer externe Konsumenten bereit.
## Zweck
Die API-Schicht nimmt HTTP-Requests entgegen, leitet diese an die Application-Schicht weiter und liefert standardisierte Responses zurueck.
## Aktueller Inhalt
- `Program.cs`
- Startpunkt der ASP.NET-Core-Anwendung.
- Registriert Application- und Infrastructure-Dienste.
- Enthält Grundkonfiguration fuer Controller und OpenAPI/Swagger.
- `appsettings.json`
- Allgemeine Runtime-Konfiguration (Logging, ConnectionString, MediatR-Lizenz, Swagger-Optionen).
- `Controllers/`
- Zielordner fuer HTTP-Controller (aktuell noch leer).
- `Options/`
- API-spezifische Konfigurationsmodelle (z. B. `SwaggerOptions`).
## Geplante Inhalte (naechste Phasen)
- Controller fuer:
- `GET /workflows/{wisagid}`
- `POST /workflows/{wisagid}/{source}/{processid}/closing`
- `GET /documents/{id}`
- Middleware fuer:
- FluentValidation-Fehlerbehandlung
- Generelle Exception-Behandlung
- OpenAPI-Dokumentation:
- Swagger in Development, optional in Production
- Firmen-/Produkt-Metadaten
- Scalar als alternative UI
## Architektur-Regeln
- Keine direkte SQL- oder EF-Core-Logik im Controller.
- Transport-spezifische Aufgaben bleiben in API; fachliche Verarbeitung erfolgt in Application.
- Einheitliches Response-Schema gemaess Ticket-Vorgabe (`meta.code`, `meta.message`).
## Rolle im Gesamtsystem
Die API ist das Eingangstor fuer externe Systeme (z. B. fabrik19) und sorgt fuer stabile, versionierbare und gut dokumentierte Endpunkte.