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/...`
|
- **Pfad**: `src/Logic/{Module}/{Feature}/Query/...`
|
||||||
|
|
||||||
#### Manager (Logic Layer)
|
#### Manager (Logic Layer)
|
||||||
- **Zweck**: Steuert die Bereitstellung der Daten. Hier erfolgt primär die Cache-Logik ("Cache-Aside") und die Koordination von Providern.
|
- **Zweck**: Steuert die Bereitstellung der Daten und koordiniert Schreibvorgänge.
|
||||||
- **Verantwortung**: Entscheidung, ob Daten aus dem Cache oder frisch vom Provider geladen werden müssen.
|
- **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
|
### Code Beispiel
|
||||||
|
|
||||||
@@ -172,5 +200,56 @@ readonly class OrderProvider
|
|||||||
return [];
|
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