advanced
Domain models versus anemic models
Размещайте rules рядом с data, которую они защищают, когда invariants central, но оставляйте simple DTOs и records, когда behavior принадлежит services или workflows.
Богатая domain model инкапсулирует бизнес-правила с данными — `order.cancel()` контролирует переходы состояния. Анемичная — контейнеры данных (DTO/records) с логикой в services. Rich model сильна при сложных инвариантах и ubiquitous language в методах; anemic — для CRUD, integration-heavy workflow и простых transport shapes.
DDD tactical patterns используют aggregates как границы согласованности; не вешайте каждое правило на каждый объект слепо.
На интервью: рефакторинг anemic `OrderService` в метод `Order` и когда не стоит.
Типовые ошибки: fat entities с persistence; anemic с дублированием логики в services; DTO в domain layer.
Компромисс — связное поведение против тонких слоёв, проще для junior и ORM mapping.
Чеклист:
- Правила с данными, которые защищают, если это центрально.
- Persistence mapping вне rich entities при необходимости.
- DTO только на API boundaries.