Domain-Driven Design
Value Objects in Domain-Driven Design
Objects defined by their attributes rather than identity — and why immutability makes them safe to share.
A Value Object has no conceptual identity; it is defined entirely by its attributes. Two Money objects representing €10 are interchangeable regardless of which instance they are. Value objects should be immutable: operations return new instances rather than mutating state. This makes them safe to share across the model without defensive copying.
final class Money
{
public function __construct(
private readonly int $amount, // in cents
private readonly string $currency,
) {}
public function add(Money $other): self
{
if ($this->currency !== $other->currency) {
throw new \DomainException('Currency mismatch');
}
return new self($this->amount + $other->amount, $this->currency);
}
}Continue reading
- →
Dependency Injection and IoC Containers
Invert control of dependency creation to keep classes decoupled from their collaborators and trivially testable.
- →
The Observer Pattern and Event-Driven Design
Decouple publishers from subscribers by letting objects register interest in events without the producer knowing who is listening.
- →
The Strategy Pattern: Encapsulating Algorithms
Define a family of algorithms, encapsulate each one, and make them interchangeable — open for extension, closed for modification.