docs: add layer readmes for architecture boundaries
This commit is contained in:
41
src/core/DigitalData.TaskFlow.Application/README.md
Normal file
41
src/core/DigitalData.TaskFlow.Application/README.md
Normal 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.
|
||||||
33
src/core/DigitalData.TaskFlow.Domain/README.md
Normal file
33
src/core/DigitalData.TaskFlow.Domain/README.md
Normal 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.
|
||||||
@@ -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.
|
||||||
44
src/presentation/DigitalData.TaskFlow.API/README.md
Normal file
44
src/presentation/DigitalData.TaskFlow.API/README.md
Normal 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.
|
||||||
Reference in New Issue
Block a user