Shared-Komponenten
Gemeinsam genutzt – aber sparsam und bewusst.
Was gehört in Shared
?
Nicht alles, was mehrfach gebraucht wird, gehört gleich ins Shared-Verzeichnis. In gut strukturierten DDD-Anwendungen sind Shared-Komponenten klar abgegrenzt und enthalten nur das, was wirklich übergreifend sinnvoll ist – z. B.:
- IDs als Value Objects (z. B.
UserId
,ProductId
) - Basis-Events oder Event-Hierarchien
- Technisch universelle Exceptions
- Hilfsklassen wie
Slugger
,ClockInterface
,TimeProvider
Strukturvorschlag
src/
└── Shared/
├── Identity/ # z. B. UserId, ProductId
├── Event/ # Basisklassen für Events
├── Exception/ # Gemeinsame Exception-Typen
└── Utils/ # Technische Hilfsklassen
Beispiel: Value Object für IDs
// src/Shared/Identity/ProductId.php
class ProductId
{
public function __construct(private string $value) {}
public function __toString(): string
{
return $this->value;
}
}
Beispiel: TimeProvider
// src/Shared/Utils/SystemTimeProvider.php
class SystemTimeProvider implements TimeProvider
{
public function now(): \DateTimeImmutable
{
return new \DateTimeImmutable();
}
}
Beispiel: Gemeinsame Exception
// src/Shared/Exception/ValidationException.php
class ValidationException extends \RuntimeException {}
Wann du lieber nicht Shared verwenden solltest
- Wenn ein Begriff in mehreren Contexts unterschiedlich verwendet wird
- Wenn du nur Kopplung vermeiden willst – dann ist explizite Abgrenzung besser
- Wenn du merkst: die Komponente verändert sich ständig pro Modul
tipp
Shared-Code sollte selten sein und stabil bleiben. Alles andere gehört in den jeweiligen Bounded Context.
Zusammenfassung
Die Shared
-Komponenten:
- Bieten technische oder universelle Unterstützung für mehrere Bounded Contexts
- Enthalten keine Domänenlogik
- Dürfen nur genutzt werden, wenn sie keinen Kontext verletzen
- Helfen bei der Wiederverwendbarkeit, ohne unnötige Abhängigkeiten zu schaffen