DDD (Domain-Driven Design) принято подавать как секретное учение с толстыми книгами, которые никто не дочитывает до конца. На деле концепция максимально утилитарна: сделать так, чтобы код перестал быть загадкой для бизнеса, а бизнес — для программиста. Это не попытка обмазаться абстракциями, а способ убрать “сломанный телефон” между теми, кто пишет код, и теми, кто на нем зарабатывает.
Домен в DDD — это не адрес сайта в строке браузера, а конкретная бизнес-область. В ритейле это товары и корзины, в финтехе — транзакции и счета. Основное правило: если бизнес называет сущность «продуктом», в коде должен быть
Product. Не Item, не RawData, не Entity123. Это убирает лишнюю прослойку в голове, когда прилетает задача «реализовать скидку на продукт», и ты сразу понимаешь, о какой части системы идет речь.Проблема начинается там, где сущности с одинаковыми названиями имеют разный смысл. Пытаться впихнуть всё в одну универсальную таблицу в БД — это архитектурное самоубийство. В контексте витрины магазина
Product — это красивое описание, фото и цена. В контексте склада тот же самый объект превращается в коробку, где важны вес, габариты и время отгрузки.Это и есть разделение контекстов (Bounded Contexts). Продавец и кладовщик говорят об одном «товаре», но оперируют разными данными. DDD учит не смешивать эти сущности в одну кучу, а разносить их по разным логическим блокам.
В коде это будут два разных класса
Product, которые просто лежат в разных папках (например, в неймспейсах Sales и Warehouse). Каждая часть системы видит только те данные, которые ей реально нужны. Проектирование на языке бизнеса напрямую влияет на чистоту реализации. Если нужно провести возврат, метод должен называться
proceedRefund(), а не updateStatus(status_id=5). Код должен описывать бизнес-процесс, а не механическую смену цифр в базе данных. Когда архитектура прозрачна и соответствует логике домена, потребность в менеджере-переводчике отпадает. Вы начинаете читать код как спецификацию, где каждое действие имеет понятный физический смысл.Хороший код — это когда бизнес-логика не похоронена под слоями абстракций, а торчит наружу через правильный нейминг и структуру.
Поделитесь этим постом с коллегой, который до сих пор называет методы updateField1(). Поможем индустрии заговорить по-человечески! 🚀
Ставь 🔥, если всё разложилось по полочкам. А если остались вопросы по реализации или что-то звучит слишком абстрактно — пиши в комменты, обязательно разберем!
10МДК