feat: define Write Pattern and Manager details
This commit is contained in:
+84
-5
@@ -109,12 +109,40 @@ Das Read Pattern beschreibt den Weg einer Datenabfrage von der UI bis zur Datenq
|
||||
- **Pfad**: `src/Logic/{Module}/{Feature}/Query/...`
|
||||
|
||||
#### Manager (Logic Layer)
|
||||
- **Zweck**: Steuert die Bereitstellung der Daten. Hier erfolgt primär die Cache-Logik ("Cache-Aside") und die Koordination von Providern.
|
||||
- **Verantwortung**: Entscheidung, ob Daten aus dem Cache oder frisch vom Provider geladen werden müssen.
|
||||
- **Zweck**: Steuert die Bereitstellung der Daten und koordiniert Schreibvorgänge.
|
||||
- **Schnittstelle**: Besitzt ein eigenes Interface in der Logic Layer zur Gewährleistung von Testbarkeit und Austauschbarkeit.
|
||||
- **Verantwortung**:
|
||||
- Read: Entscheidung zwischen Cache (Cache-Aside) und Provider.
|
||||
- Write: Triggerung der Cache-Invalidierung nach erfolgreichen Änderungen.
|
||||
- **Zustand**: Strikt zustandslos (stateless).
|
||||
|
||||
#### Provider (Data Layer)
|
||||
- **Zweck**: Führt die technische Abfrage gegen die Infrastruktur aus (DB, API).
|
||||
- **Rückgabewert**: Liefert die **Kern-Business-Models** zurück, nicht notwendigerweise die technischen Entities der Datenbank.
|
||||
|
||||
...
|
||||
102: ### Der Datenfluss
|
||||
103: `UI Layer` $\rightarrow$ **BusinessQuery** $\rightarrow$ **Manager** $\rightarrow$ **Provider**
|
||||
104:
|
||||
105: #### BusinessQuery (Logic Layer)
|
||||
106: - **Zweck**: Dient als fachlicher Einstiegspunkt für Leseoperationen. Sie orchestriert Manager oder andere Queries, um ein Endresultat zu formen.
|
||||
107: - **Struktur**: Implementiert das gleiche Muster wie UseCases (`execute()` Methode).
|
||||
108: - **Input/Output**: Nutzt Request-DTOs (besonders für Filter und Pagination) und gibt Response-DTOs zurück.
|
||||
109: - **Pfad**: `src/Logic/{Module}/{Feature}/Query/...`
|
||||
110:
|
||||
111: #### Manager (Logic Layer)
|
||||
112: - **Zweck**: Steuert die Bereitstellung der Daten. Hier erfolgt primär die Cache-Logik ("Cache-Aside") und die Koordination von Providern.
|
||||
113: - **Verantwortung**: Entscheidung, ob Daten aus dem Cache oder frisch vom Provider geladen werden müssen.
|
||||
114:
|
||||
115: #### Provider (Data Layer)
|
||||
116: - **Zweck**: Führt die technische Abfrage gegen die Infrastruktur aus (DB, API).
|
||||
117: - **Schnittstelle**: Die Provider-Interfaces liegen zwingend in der **Logic Layer**, um Dependency Inversion zu gewährleisten.
|
||||
118: - **Rückgabewert**: Liefert ausschließlich **Kern-Business-Models** zurück.
|
||||
119: - Einfache Listen $\rightarrow$ `array` (mit PHPDoc `@return Model[]`).
|
||||
120: - Paginierten Listen $\rightarrow$ Ein Wrapper-Objekt (z. B. `PaginatedCollection`), das Daten und Metadaten enthält.
|
||||
121: - **Fehlerbehandlung**: Wirft im Fehlerfall direkt **Domain-Exceptions**.
|
||||
122: - **Parameter**: Nutzt für einfache Lookups primitive Typen (`string`, `int`), für komplexe Abfragen DTOs.
|
||||
123: - **Granularität**: Ein Provider pro Business-Model.
|
||||
124:
|
||||
125: ### Code Beispiel
|
||||
...
|
||||
|
||||
### Code Beispiel
|
||||
|
||||
@@ -172,5 +200,56 @@ readonly class OrderProvider
|
||||
return [];
|
||||
}
|
||||
}
|
||||
|
||||
## 3. Write Pattern (`src/Logic` $\rightarrow$ `src/Data`)
|
||||
|
||||
Das Write Pattern definiert den Weg von einer Zustandsänderung hin zur Persistenz. Es stellt sicher, dass Schreiboperationen atomar erfolgen und die Integrität der Business-Models gewahrt bleibt.
|
||||
|
||||
### Der Datenfluss
|
||||
`UI Layer` $\rightarrow$ **UseCase** $\rightarrow$ **Manager** (optional) $\rightarrow$ **Processor**
|
||||
|
||||
#### Processor (Data Layer)
|
||||
- **Zweck**: Übernimmt die physische Persistierung eines Business-Models.
|
||||
- **Schnittstelle**: Das `ProcessorInterface` liegt zwingend in der **Logic Layer** (Dependency Inversion).
|
||||
- **Input**: Ein Business-Model.
|
||||
- **Rückgabewert**: Das aktualisierte/neu erstellte Business-Model (z.B. zur Rückgabe von generierten IDs).
|
||||
- **Fehlerbehandlung**: Wirft im Fehlerfall direkt **Domain-Exceptions**.
|
||||
- **Strategie**: Verfolgt den "All or Nothing" Ansatz; die übergeordnete Transaktion wird vom UseCase gesteuert.
|
||||
- **Granularität**: Fokus auf eine einzelne Entität pro Processor.
|
||||
|
||||
### Code Beispiel
|
||||
|
||||
#### Processor Interface & Implementierung
|
||||
```php
|
||||
namespace App\Logic\Sales\Order;
|
||||
|
||||
use App\Logic\Sales\Order\Model\Order;
|
||||
|
||||
interface OrderProcessorInterface
|
||||
{
|
||||
public function save(Order $order): Order;
|
||||
public function delete(string $id): void;
|
||||
}
|
||||
|
||||
// --- Data Layer ---
|
||||
namespace App\Data\Sales\Order\Processor;
|
||||
|
||||
use App\Logic\Sales\Order\OrderProcessorInterface;
|
||||
use App\Logic\Sales\Order\Model\Order;
|
||||
|
||||
readonly class OrderProcessor implements OrderProcessorInterface
|
||||
{
|
||||
public function save(Order $order): Order
|
||||
{
|
||||
// Persistenz-Logik (DB/API) ...
|
||||
return $order; // Hier ggf. mit generierter ID zurückgeben
|
||||
}
|
||||
|
||||
public function delete(string $id): void
|
||||
{
|
||||
// Lösch-Logik ...
|
||||
}
|
||||
}
|
||||
```
|
||||
```
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user