День 2319. #ЗаметкиНаПолях
DTO и Маппинг: Хорошее, Плохое, Лишнее. Окончание
Начало
CQRS для иллюстрации DTO в действии
В CQRS вы разделяете систему на две части:
1. Запросы отвечают за извлечение и составление данных, возвращая данные, адаптированные для конкретных вариантов использования.
2. Команды отвечают за намерение и действия, такие как обновление или удаление данных.
При этом ваши ответы на запросы по сути являются DTO, которые содержат все объединённые данные, необходимые для конкретного варианта использования. Например, если вы создаёте UI для отображения сведений о заказе, DTO запроса может включать не только данные заказа, но и сведения о клиенте и доступные действия, такие как «Выполнить» или «Отменить».
Команды, с другой стороны, представляют собой конкретные действия, которые вы хотите выполнить. Вместо того чтобы думать в терминах общих операций CRUD, вы думаете в терминах команд, специфичных для домена, таких как «ОтменитьЗаказ» или «ОтметитьЗаказОплаченным». Эти команды инкапсулируют намерение и поведение, а не просто обновления данных.
CQRS не требует разных БД для команд и запросов. Он больше про то, как вы моделируете свою систему и её взаимодействия. Команды и запросы могут работать с одной БД, но представлять разные модели и DTO, адаптированные для их конкретных целей.
Размышления о DTO
1. Внешние и внутренние данные
- Внутри - данные приватные для системы, детали реализации: схема БД и модели домена.
- Снаружи - данные, предоставляемые публично: контракты API или сообщения в очереди.
Цель в сохранении конфиденциальности внутренних данных, чтобы вы могли развивать и изменять их, не влияя на внешних потребителей. Внешние данные следует рассматривать как контракт, который необходимо тщательно версионировать, поскольку вы не контролируете всех потребителей.
Если вы владеете обеими сторонами взаимодействия и можете эффективно управлять связанностью, возможно, DTO не нужны везде. Но если вы предоставляете данные внешним сторонам или хотите разделить слои, чтобы обеспечить независимую эволюцию, DTO бесценны.
2. Количество потребителей
Сколько потребителей зависят от вашей внутренней модели данных? Если всего пара, и вы хорошо управляете связью, вы можете спокойно возвращать сущность напрямую без DTO. Если 50+, это, вероятно, признак того, что нужно ввести уровень абстракции с DTO, чтобы избежать критических изменений и защитить внутренние модели.
Не перебарщивайте с DTO
Часто люди увлекаются и создают множество слоёв отображений DTO-на-DTO-на-другие-DTO. Это только добавляет сложности без реальной выгоды. Если ваши DTO и сущности почти идентичны, и вы просто копируете данные туда-сюда, это уже лишняя работа.
DTO должны служить чёткой цели, например:
- Разделение внутренних моделей данных от внешних контрактов;
- Составление данных из нескольких источников для конкретных вариантов использования;
- Добавление версионирования для публичного API.
Итого
- DTO в первую очередь предназначены для управления связями и композицией данных. Они помогают избежать раскрытия деталей внутренней реализации и позволяют формировать данные, адаптированные для конкретных потребителей.
- Не создавайте DTO просто так. Если внутренние модели и внешние потребители жёстко контролируются и ограничены, может быть удобно возвращать сущности напрямую.
- Остерегайтесь чрезмерных слоёв сопоставления. Они только добавляют ненужной сложности.
- Используйте шаблоны, вроде CQRS, чтобы по-другому думать о запросах и командах. Это помогает моделировать данные и действия таким образом, чтобы они естественным образом соответствовали DTO и композиции.
- Думайте о данных как о внутренних (частных) и внешних (публичный контракт). Такой образ мышления поможет решить, где необходимы DTO и как версионировать ваш API.
Источник: https://codeopinion.com/dtos-mapping-the-good-the-bad-and-the-excessive/
>>Click here to continue<<