Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 15
А где пример на бизнес логику?
А то у меня подобный рефакторинг получился на 10 kloc (один merge request) и основная причина этого выявить скрытую логику, сконцентрировать её в домене. В итоге, повысить стабильность и снизить риски при доработках
Не ради цифры, а ради того чтобы критичные пути были покрыты тестами
А как цифра 87% гарантирует или хотя бы показывает, что критичные пути покрыты?
DDD это не про паттерны ради паттернов. Это про то чтобы бизнес-логика не зависела от фреймворка
Вообще-то, есть куча подходов, где бизнес-логика выделена в отдельный слой/модуль. То есть, это не уникальное свойство DDD и не в DDD это придумали.
А как цифра 87% гарантирует или хотя бы показывает, что критичные пути покрыты?
Согласен, 87% это метрика дисциплины, не качества. Реальная защита была бы через покрытие конкретных use case: GetBranchReport, расчёт выручки, агрегация остатков. Цифра просто не даёт скатиться ниже порога.
Вообще-то, есть куча подходов, где бизнес-логика выделена в отдельный слой/модуль. То есть, это не уникальное свойство DDD и не в DDD это придумали.
Не претендовал на уникальность DDD в этом вопросе. Clean Architecture решает то же самое. Выбор был прагматичный, так как команда знала DDD, переходить на другой подход было дороже, чем результат.
А как цифра 87% гарантирует или хотя бы показывает, что критичные пути покрыты?
Согласен, 87% это метрика дисциплины, не качества. Реальная защита была бы через покрытие конкретных use case: GetBranchReport, расчёт выручки, агрегация остатков. Цифра просто не даёт скатиться ниже порога.
Вообще-то, есть куча подходов, где бизнес-логика выделена в отдельный слой/модуль. То есть, это не уникальное свойство DDD и не в DDD это придумали.
Не претендовал на уникальность DDD в этом вопросе. Clean Architecture решает то же самое. Выбор был прагматичный, так как команда знала DDD, переходить на другой подход было дороже, чем результат.
там легаси погоняет легаси
С точки зрения SQL-щика там легаси не при чём, просто там болван доделывал за идиотом. Вот как вся эта архитектура БД могла жить годами - ГОДАМИ! - без индексов? КАК? Там должно было тормозить всё, везде и всегда, и никакой Постгресс это не вывезет.
При этом непонятен вот какой момент. Поверх СУБД работает ORM. Чтобы она правильно понимала, с чем работает, в модели должны быть описаны связи, а на стороне СУБД это должно быть поддержано соответствующими внешними ключами и необходимыми для их обслуживания индексами. Но индексов-то НЕТ! Как же оно так существовало-то?
К слову, и проблема N+1 тоже не сама появилась - она создана добрыми руками очередного программиста, написавшего вот тот кривой код, который вы нам показываете.
В общем, всё описанное как-то слабо похоже на правду, скорее это придуманный, но не продуманный синтетический пример.
PS. К тому же уж больно сильно смахивает на недавно опубликованную, раскритикованную за кучу ошибок и в результате безвозвратно снятую с публикации статью за авторством одной дамы - почти что с точностью до текстов запросов.
легаси без индексов годами, это не баг, а рынок. Кто не встречал, тому повезло. ORM и Django проекты живут по своим законам, это немного другой мир)) По поводу похожей статьи, жду ссылку. Пока звучит как легенда.
По поводу похожей статьи, жду ссылку. Пока звучит как легенда.
Ничем не могу помочь - статья снята с публикации, и соответственно недоступна, в том числе на посмотреть или просто дать ссылку. А, судя по количеству и особенно качеству ошибок, ожидать её ре-публикации бессмысленно..
легаси без индексов годами, это не баг, а рынок. Кто не встречал, тому повезло. ORM и Django проекты живут по своим законам, это немного другой мир
Но у вас-то все они живут в одной системе. Нет, если вы скажете, что в Django возможно такое, что связи в модели есть, а внешних ключей да индексов, соответствующих этим связям, нет и никогда не было - поверю как имеющему дело с этой ORM, ибо сам не владею в принципе, а изучать по такому поводу уж точно лень. Просто поставлю в уме ещё один жирнючий минус.
просто там болван доделывал за идиотом
Пу-пу-пу.. вы слишком категоричны. Истинная проблема скорее всего в том, что там всего два-три разработчика.. и это сервисное подразделение, где сайтик на django был напилен в частном порядке чтобы сократить рутину.. и разработка не является профильным направлением.
Вот как вся эта архитектура БД могла жить годами - ГОДАМИ! - без индексов? КАК?
Предположу что подразделение пилит отчеты и витрины данных для других подразделений. Это практически всегда означает, что там даже первичных ключей может не быть, и большинство таблиц перезаливается как есть.. каждый раз. Без индексов. Работает и работает, хер с ней.
У нас именно так. Правда не pg, а sql server и я в частном порядке раз в месяц на основе статистики проверяю не надо ли куда-нибудь прикрутить очередной индекс. Но все так как описано в статье.
С точки зрения SQL-щика там легаси не при чём
И мы как раз SQLщики. Приходится поддерживать огромное количество кода, к которому ты не имеешь никакого отношения.. так еще и никакой документации, и "потрясающие технические решения" многие из которых незакончены их авторами. Это и есть легаси когда "работает - не трогай", а потом "да блт как оно работает то?".
Типичная история в телекоме, сотрудник начинает заскриптовывать рутину, это выливается в кучу вью, процедур или кода на сайтике.. а потом он понимают что за эту херню ему тут не платят, он увольняется и уходит джуном куда-нибудь в финтех.
Поверх СУБД работает ORM. Чтобы она правильно понимала, с чем работает, в модели должны быть описаны связи, а на стороне СУБД это должно быть поддержано соответствующими внешними ключами и необходимыми для их обслуживания индексами.
Как я уже говорил.. витрины данных. Со временем у них появляется N пользователей, которые хотят увидеть все это в вебе.. и обогатить данными из других бд. Получается типичнейший database first подход.
К слову, и проблема N+1 тоже не сама появилась - она создана добрыми руками очередного программиста, написавшего вот тот кривой код, который вы нам показываете.
Вы смотрите на проблему глазами программиста который имеет в своем прокте code first, до десятка таблиц, там же прописана документация, комменты и все чин-чином. У вас там методологии, best practice, паттерны, архитектуры и лавандовый раф. В описываемом случае скорее всего тысячи и тысячи обьектов в разных бд, которые пилились без каких либо договоренностей далекими от computer science людьми. Например у нас это делали специалисты радиопланирования, специалисты оптимизации радиосети, картографы и тд.
Да, исторически SQL задумывался как непроцедурный язык для «широкого круга пользователей», включая менеджеров, аналитиков и домохозяек не знакомых с программированием
Не стоит требовать знаний решения проблемы N+1 от людей, чья специфика работы никак с этим не связана. Он просто закончил курс "делаем сайты на php" и делает свою автоматизацию из говна и палок.. это не его вина что получившееся поделие обретет свою собственную жизнь после его ухода из компании.
не продуманный синтетический пример
Я в таком синтетическом примере работаю уже дольше, чем негр-скрипач на плантации, поэтому могу вам с уверенностью заявить что все так. Вы еще вероятно не видели как у отдельных уникумов SQL собирается в hidden полях на фронте. Или безопасников которые все это тестируют, и не находят проблем с инжекцией, а ты знаешь что они есть.. и все это пафосно обернуто в красивую "продуктовую" упаковку.
По моему опыту всем этим правильным некому заниматься. Время от времени в подразделение приходят люди с горящими глазами, начинают пытаться расчистить эти авгиевы конюшни.. а это никому не надо. Глаза тускнеют, и вот через N месяцев он уходит куда-то в полноценное IT, где понимают о чем он говорит, и где можно чему-то научиться. Научиться.. я не могу научить людей пользоваться гитом, за нейминг у нас была битва, а кодстайл так никто и не осилил. Толстые контроллеры и спагетти код без какого-либо логического разделения ответственности в порядке вещей.
это не просто «медленно». Это экспоненциальный рост
Это не магия, это базовая гигиена работы с ORM
N+1 это не мелочь, это смерть под нагрузкой.
DDD это не про паттерны ради паттернов. Это про то чтобы бизнес-логика не зависела
это не перфекционизм. Это экономика.
Нейронка писала, да?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Монолит с отчётами на 30 секунд: как я переписал архитектуру и что из этого вышло