Автор: Александр Алексеев · Папочка Разработки
Александр Алексеев ведёт канал о .NET-разработке, где объясняет архитектурные концепции без академической перегруженности. Это видео — один из лучших русскоязычных входных точек в DDD: без Эванса на 500 страниц, но с сохранением сути.
Domain-Driven Design принято считать сложным — и чаще всего путают причину сложности. Дело не в паттернах: агрегаты, репозитории, value objects можно выучить за вечер. Настоящая сложность DDD в другом: он требует, чтобы разработчики говорили на одном языке с теми, кто понимает предметную область. Без этого единого языка — Ubiquitous Language в терминах Эванса — код отражает не бизнес-логику, а то, как разработчик её понял. В больших системах этот разрыв со временем становится главным источником багов и рефакторингов.
Александр разбирает, почему DDD особенно важен именно для сложных, долгоживущих систем и почему его не стоит тащить в простые CRUD-приложения — это отдельный тезис, который стоит услышать до того, как начинать внедрение.
Кому смотреть: backend-разработчикам, которые слышали про DDD, видели аббревиатуру в вакансиях, но не понимают, зачем это нужно и когда это оправдано.
Из этого можно взять в работу: возьми любую сущность в своём коде — например, Order. Спроси себя: это слово означает одно и то же для разработчика, менеджера и бухгалтера? Если нет — у вас нет Ubiquitous Language, и DDD пока не начинался.
DDD — это прежде всего методология работы с предметной областью, а не набор паттернов реализации. Эрик Эванс в своей книге разделяет стратегический и тактический дизайн. Стратегический — это про то, как разбить большую систему на Bounded Contexts, где у каждой части своя модель и свой язык. Тактический — это уже агрегаты, сущности, value objects, доменные события.
Распространённая ошибка — брать тактические паттерны без стратегического фундамента. Команда делает «DDD», потому что использует Repository и Entity, но при этом вся бизнес-логика размазана по сервисам или хуже — по контроллерам. Это не DDD, это просто нейминг из книжки.
Bounded Context — ключевая концепция для больших систем. Customer в контексте продаж и Customer в контексте службы поддержки — это разные объекты с разными атрибутами и поведением. Попытка сделать одну универсальную модель клиента для всей компании — классический anti-pattern, который ведёт к гигантским, хрупким агрегатам.
Про «типичные ошибки при внедрении», о которых говорит Александр: анемичная модель (сущности без поведения, только с геттерами/сеттерами), игнорирование Ubiquitous Language (код на русском, комментарии на английском, а в голове у аналитика — третий вариант), и преждевременное применение DDD там, где хватило бы простого CRUD.