Comments 22
Если эффективность, масштабируемость и производительность вашему приложению/бизнесу "не интересны", то "объектный подход" вам вполне подойдет.... :-)
При изменении правил нужно менять всё
При изменении правил вам так или иначе придётся менять всё. Либо переписывать код вместе с SQL запросами, либо переписывать кучу слоёв абстракции. А так-то DDD дело хорошее. Ну по крайней мере в теории.
Хорошее руководство для новичков, но я бы добавил про порты/интерфейсы/usecase.
A дальше вам надо маппить ваши сущности на базу данных а потом на rest интерфейсы, а потом все это как-то поддерживать на протяжении Х лет. Сколько лет проживает ваш. Питоновский код, а сколько базы данных? Пока счёт 1:0 в пользу баз данных. Если где и жив legacy code то только в приложении к базам данных. Это как раз проблема cobol, на котором написали кучу бизнес логики и как ее теперь на другой стек переписать никто не знает. С базами данных проблем нет - как лежали данные в таблицах и обрабатывались sql запросами так и продолжают лежать.
Про маппинг согласен, эти преобразования на каждом слое отнимают время
Вопрос в том кто это будет писать/ отлаживать и поддерживать. Если вы проектирует не от структур данных, то у вас через Х итераций будет полный треш. И что за что отвечает, где храниться и где у нас мастер данные понять будет невозможно.
Я Тут как раз в одном код-ферст проекте развдекаюсь - треш полный.
Если начинать проектирование с данных/ БД то потом можно на основании структуры данных генерить любые классы любым инструментом сохраняя при этом нормальную структуру.
Как только вы начинаете с другого конца- бизнес прави или чего угодно у вас будет треш.
SQL-транзакций в языке бизнеса нет, поэтому и в коде не будет?
Транзакции вообще-то есть, расположены они как раз в домене. А вот их реализация в DB слое. Если я все правильно понимаю
Транзакции как правило не в домене, а в сервисе, так как транзакция предполагает изменение нескольких entity. На слое сервиса создаются репозитории для работы с базой, unit of work, в котором как раз инициализируется транзакция и репозитории. Вся логика выполняется на этом сервисе, вызывая необходимые методы репозитория, а так же вызов commit и rollback. Сама реализация commit и rollback сделана на уровне DB
И.е. Выкинем базу данных ГТК профи писали поддержку транзакций и напишем свою. А потом удивляемся что все валится и не работает?
Не понял, почему выкинем базу данных, почему напишем свою поддержку транзакций? В persistense используем то, что написали эти самые профи, просто там оставляем непосредственно логику работы БД, а логика работы сервиса лежит отдельно.
Открываем руководство к любой базе данных. Раздел уровни изоляции транзакций. Вдумчиво читаем: что происходит какие побочные эффекты возможны. Закрываем и типа реализуем на уровне сервиса …. Транзакция это согласиюоыанные изменения данных. Если вы их от уровня БД оторвали то там уже терт знает что произойдет и никто не знает как оно на самом деле будет. Кроме того ваши сервисы скорее всего растащат по разным пользователям/ базам данные. И реализовать согласованность на уровне БД вы запаритесь. Скорее всего будет уровня «и так сойдет»
Ну вот я не вижу, где в примере о бронировании номера хоть какая-то транзакционность или просто атомарность.
Незанятость номера проверяется, ага. А если через 1 мс она изменится потому что кто-то другой забукал номер?
Если всё это завёрнуто в одну большую транзакцию, то где обработка нарушения ограничений при её коммите?
Похоже, что эти безусловно красивые абстракции только помешают довести этот прототип до уровня production ready
Я вижу тут только чистый код, separation of concerns и ОО. Слоистая или в лучшем случае гексагональная архитектура
DDD подразумевает проектирование, в статье проектирование не показано, только то, что может быть одним из результатов
Мощнейшее добавление DDD к ООП — это более явное выделение контекстов и переопределение (перегрузка) классов в разных контекстах, в статье этого нет
Если сравнивать с кодом где вручную без ORM фигачить везде execute с запросами. Ну как минимум сравниваем с наихудшим решением без какой-либо архитектуры. Тут не то что Domain модель делает лучше, да тут любая нормальная архитектура будет лучше...
Странно, что в статье ссылки нет на вот эту книгу https://www.cosmicpython.com/book/preface.html
DDD на пальцах: как перестать проектировать таблицы и начать думать о бизнесе