Zum Hauptinhalt springen

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