domain-driven-design

# Domain-Driven Design ## Aggregate Rules - One repository per aggregate root - External code only accesses aggregate through root — never child entities directly - Prefer references by ID across aggregate boundaries; preserve deliberate mappings. - Choose boundaries from invariants that must commit atomically and expected contention, not a fixed number of child entities. Splitting requires an explicit consistency plan. The snippets are illustrative and require the application's domain types and imports. Keep existing public identifiers and persistence mappings unless the task includes a migration. ```java // ✅ Aggregate root controls all access to children order.addItem(productId, quantity); // through root order.removeItem(itemId); // through root // ❌ Direct child access from outside order.getItems().add(new OrderItem(...)); // bypasses invariants ``` ## Value Objects Immutable, no identity, equality by value: ```java public record Money(BigDecimal amount, Currency currency) { public Money { if (amount.compareTo(BigDecimal.ZERO) < 0) throw new IllegalArgumentException("Amount cannot be negative"); Objects.requireNonNull(currency); } public Money add(Money other) { if (!currency.equals(other.currency)) throw new CurrencyMismatchException(currency, other.currency); return new Money(amount.add(other.amount), currency); } public static Money of(String amount, String currency) { ...