Comments 4
в очередной раз про DDD и в очередной раз непонятно
можно простыми словами, для глупых?
что такое DDD, в чём суть?
Целью DDD является улучшение коммуникации и структуры
между различными областями знаний и создание общего языка, понятного
всем членам вашей команды.
Какой ещё общий язык, понятный всем членам команды? English, bug-tracker, task-tracker - вот наш язык.
Цель - улучшение коммуникации между различными областями знаний - типа более продвинутое, гибкое API или что зашифровано здесь?
вот у нас есть OOP (ООП) - подход, когда наш код разделён на объекты, которые задаются классами, которые должны обеспечивать контракты (имплементировать интерфейс) или просто быть написаны как святой пирог на душу положил.
Соответственно, вот у нас раньше было куча кода в 5ти файлах, например, это php или js
И вот мы взяли и переписали их в ООП-парадигме - поделив и представив весь код в виде классов, по которым в ран-тайме будет варить объекты. Мы получили вместо 5 файлов условно 200, но каждый файл представляет какой-то класс, по которому инстанциируется его объект - ну и дальше уже там объекты взаимодействуют между собой, реализуя бизнес логику.
Так вот.
Где. В каком месте. Как. Подключается в вот эту модель DDD? Что нужно сделать с вот этим кодом, чтобы вышло DDD? какой даст профит?
"DDD" — это подход к проектированию программного обеспечения, который
расшифровывается как предметно-ориентированное проектирование,
сфокусированное на моделировании программного обеспечения для
соответствия бизнес-домену согласно данных, полученных от экспертов
этого домена.
То есть, мы как-то делим код на предметы/домены? Проектирование, сфокусированное на моделировании для соответствия бизнес-домену -- что такое бизнес-домен? Что это за данные, полученные от экспертов домена? Эксперты домена - это просто пользователи? Бизнес-домен - это какой-то кусок чего-то, бизнеса, сервиса, как его определить? Это корзина в интернет-магазине? Это какой-то сервис в мобильном телефоне? Возможно "забронировать" билет?
И как вы поняли, что пора в DDD? Вот как-то же был до того продукт/сервис/сайт, и вот он как-то проектировался архитекторами по хотелкам овнеров/аналитиков, окей - это и были эксперты домена? Или если не они, то кто новые таск-мейкеры?
Вот была у нас платформа, состояла из 50 микросервисов. Можно ли их переписать на DDD? Нужно ли? Как это понять? В чём суть?
Вот с ооп очень легко - если нужна единичная процедура, функция, скрипт, хело-ворлд какой-то - берёшь и пишешь просто код в скрипте. Затем кода становится много, что-то можно вынести в класс, который станет ответственным за какие-то объединённые общими операциями вещи.
Просто в очередной раз вижу статью про DDD, написанную теми, кто практикует DDD для тех, кто уже архитектор или даже не знаю кого. Вот для джунов можно написать? Чтобы ты зашёл и такой - "ага, это - домен. Это - эксперт. В коде это выглядит вот так". Какие-то, может, UML-диаграммы нарисовать, хз
Я тоже не понял о чём статья
когда-то очень давно были 2 концепции программирования Object-Oriented-Programming и Domain-Data-Driven
При DDD кажется описание модели должно было задаваться через регистрацию кучи параметров в виде данных для единообразного обработчика всех типов модели
При OOP описание модели задаётся через отдельные обработчики для каждой модели
Как-то так была основное отличие
Выжила концепция OOP - которой сейчас пользуются все и большинство языков программирования под эту идею заточено.
хотя гугление хабра даёт https://habr.com/ru/post/334126/
прочитал - но, к сожалению, тоже мало что понял. Оно как-то у них неясно откуда начинается и неясно куда уходит и через что. Ну, это, наверное, интересно читать тем, кто уже делает что-то такое же, но своё, но вот я, как не осознавший, что это за DDD, не могу въехать и "прохавать", в чём суть
например, я могу понять, в чём суть MVC или там TDD и скорее всего сяк-так я смогу это реализовать в коде. Функциональное программирование - тоже вроде понятно, меняем подход к построению функций, не везде применимо, но вроде понятно. Вот есть ещё REST - типа как тоже архитектурный стиль, у него там есть какие-то подходы, которые если выполнить, то API будет RESTful и получит какие-то свои бенефиты от такого подхода, в расширяемости там или ещё в чём
А как доходит до DDD - начинается какая-то мистика, какие-от модели, планирование, домены и эксперты, и вроде все практикуют, но донести простым языком не могут. По крайней мере, у меня не вышло понять.
Вот дадут мне проект, скажут - напиши код - я напишу код.
Попросят - сделай MVC. Ну, заморочусь, растасую
Попросят - сделай TDD. Тоже можно. Или там "хотим только plain sql" или тма "можно ORM" - на каждом таком шаге понятна суть, понятно, что даст этот подход или построение.
Но вот если попросят - сделай DDD - без понятия, как его начинать. Что должно быть доменом и может ли класс описывать домен - или нужно 10 классов или что это.
Самое понятное объяснение сути DDD что я встречал https://m.youtube.com/watch?v=CR9mLGN9jh0
Практическое DDD. Часть 1: Создание правильных основ