Я, кстати, удивлен тем что люди говорят про холодный старт ide. У меня pycharm открывается дай бог 5 секунд (не замерял, возможно быстрее, возможно я индексацию учитываю). Делаю я это раз в несколько дней, вообще не замечаю. Зато там есть куча функций по работе с кодом, которые на "LSP" не натягиваются
Пробовал полгода назад, криво рисовалось всё, начиная от неверного рендеринга шрифтов, заканчивая неверным размером меню. Это наблюдалось у меня, но большую часть мои товарищи не видели. Не все было смертельно, но сильно портило впечатление от редактора. Что-то за это время вроде исправили, например шрифты, но последние версии я не смотрел.
Академические решения не так далеки от реальности, вопрос в том что иногда их начинаюти перевирать и придумывать ограничения которых не было. Решениие когда мы следим только за инвариантами агрегата - понятное. Вопрос в том что автор статьи зачем-то предлагает более сложные ситуации решать ещё более сложным способом. Я предполагаю почему - такое писал Вернон и другие подхватили. Доменные события хороши для уведомления других контекстов, но если оно в одном контексте и хорошо ложиться на одну транзакцию - зачем? В статье упоминается масштабирование, но не рассказывается структура оркестратора и проблемы реализации откатов
Получив событие, Saga ReassignSubordinatesSaga запускает процесс переподчинения. Каждый шаг этой Saga обновляет ровно один агрегат (другого сотрудника), и так до тех пор, пока всех подчиненных не переведут.
Ну если на то пошло, то у меня есть кейс вставки данных по 100000 товаров в бд. Если бы я на каждый открывал транзакцию - я бы до сих пор занимался вставкой. А так я вставлял группками по 1000 "агрегатов" за раз и коммитил, транзакции были больше, но не слишком большие. При рестарте я просто проверял что уже вставлено (за один простой запрос) и продолжал так же.
Подскажите где вы нашли это у Эванса? Насколько я помню, он этого не предлагал, а это уже придумали после него и в целом сомнительно. Заменить транзакцию на саги с откатом - это очень сильное усложнение. Если у вас агрегаты относятся к одному ограниченному контексту, преимуществ этого подхода не видно.
это не просто бесполезно, но ещё и вредно. Вы показываете просто, что глобальные переменные внутри функции присваивать нельзя, это не имеет отношения к тому в каком модуле определены. А ещё у вас разные по смыслу и разные по тому как ими будут управлять вещи оказываются вместе. Это кажется удобным пока их 10 штук, но становится болью когда у вас большой проект - деление на модули просто теряется. Если у вас есть константы, которые вы хотите менять между релизами - окей, кладите вместе. Или вообще положите в конфиг. А всё что касается специфики реализации конкретных частей - оставьте в них. Нет никакого смысла класть вместе константу NOT_FOUND=404, список полномочий администратора и перевод текста "не найдено" на китайский.
Enum - это вообще не про константы. Это про тип у которого есть фиксированный набор вариантов. То что там есть value - удобно в определнных случаях, но вообще не отражает его суть. Идея Enum в том, что если в каком-то месте объект может иметь несколько вариантов, которые обрабатываются по разному, то вместо магических значений вы сразу фиксируете тип с перечислением значений и фиксируете смысл каждого его названием. Value тут чисто случайно, его надо использовать с осторожность, в основном enum нужен именно чтобы проверять `obj is MyEnum.SMTH`
С логированием вы тоже немного промахнулись. Сам по себе dictConfig это ок, но он нужен не для получения экзмпляра logger, он нужен для однокркатной настройки всего logging. Дальше логгеры получайте через logging.getLogger, как правило удобнее сделать getLogger(__name__), но в редких случаях может быть удобна другая иерархия. В любом случае, настройка логгеров и получение - две разные вещи, не смешивайте!!!
Нормальная инкапсуляиция - выделение интерфейсов, когда вы просто заявляете что есть, а об остальном потребитель ни сном ни духом. Все эти "private" в языках наследников c++ - от бедности, когда технтчески понадобилось светить все внутренности потребителю класса и не надо проводить с ними параллели и пытаться повторить.
микросервисы решали проблему человеческой памяти архитектурными средствами. AI решает проблему человеческой памяти напрямую, без архитектурных костылей.
Ерунда, напишите код, нарушающий все возможные архитектурные принципы, где каждая фича размазана по всей кодовой базе, где компоненты не существуют принципиально и ни о какой зоне отвественности не идет речь.
Архитектурные границы и правила организации кода - это как раз способ не держать в конетксте всё и уметь быстро найти. Нарушьте это и ваша нейросеть будет страдать так же как человек.
Хотелось бы чтобы доменный слой можно было организовывать исходя из потребностей конкретного домена, а натягивать на примитивы фреймворка. Например, почему бы не существовать операциям, затрагивающим несколько агрегатов. И куда делись все дополнительные адаптеры, доменные сервисы и стратегии которые мы тоже хотим инжектировать? А как насчет приложений которые не имеют постоянного стейта в бд? Много вопросов, не надо превращать DDD в CRUD
В пет проекте у меня покрытие 93%. Какой же это кайф рефакторить. Я на днях взял и переписал значительный кусок и просто следил что все тесты прошли. Если бы у меня их не было, я не знаю как бы с этой задачей справился - очень много вещей стреляло, о которых я уже даже не помнил
А замерьте сколько LSP жрет, в продуктах jetbrains это же не отдельный процесс.
Я, кстати, удивлен тем что люди говорят про холодный старт ide. У меня pycharm открывается дай бог 5 секунд (не замерял, возможно быстрее, возможно я индексацию учитываю). Делаю я это раз в несколько дней, вообще не замечаю. Зато там есть куча функций по работе с кодом, которые на "LSP" не натягиваются
Пробовал полгода назад, криво рисовалось всё, начиная от неверного рендеринга шрифтов, заканчивая неверным размером меню. Это наблюдалось у меня, но большую часть мои товарищи не видели. Не все было смертельно, но сильно портило впечатление от редактора. Что-то за это время вроде исправили, например шрифты, но последние версии я не смотрел.
Академические решения не так далеки от реальности, вопрос в том что иногда их начинаюти перевирать и придумывать ограничения которых не было. Решениие когда мы следим только за инвариантами агрегата - понятное. Вопрос в том что автор статьи зачем-то предлагает более сложные ситуации решать ещё более сложным способом. Я предполагаю почему - такое писал Вернон и другие подхватили. Доменные события хороши для уведомления других контекстов, но если оно в одном контексте и хорошо ложиться на одну транзакцию - зачем? В статье упоминается масштабирование, но не рассказывается структура оркестратора и проблемы реализации откатов
Ну если на то пошло, то у меня есть кейс вставки данных по 100000 товаров в бд. Если бы я на каждый открывал транзакцию - я бы до сих пор занимался вставкой. А так я вставлял группками по 1000 "агрегатов" за раз и коммитил, транзакции были больше, но не слишком большие. При рестарте я просто проверял что уже вставлено (за один простой запрос) и продолжал так же.
Подскажите где вы нашли это у Эванса? Насколько я помню, он этого не предлагал, а это уже придумали после него и в целом сомнительно. Заменить транзакцию на саги с откатом - это очень сильное усложнение. Если у вас агрегаты относятся к одному ограниченному контексту, преимуществ этого подхода не видно.
Делается приватное поле с геттерами и сеттеоами вместо публичного, чтобы в будущем при появлении логики при гете/сете api (и abi!) не поменялось.
берете openapi спеку и везде используете. в чем разница?
так он почти ничего не решает, а местами наоборот проблем приносит
ну да, ну да
Я думаю если ты дворник которому на еду еле хватает и при этом платишь огромный налог, это достаточно показательно
это не просто бесполезно, но ещё и вредно. Вы показываете просто, что глобальные переменные внутри функции присваивать нельзя, это не имеет отношения к тому в каком модуле определены. А ещё у вас разные по смыслу и разные по тому как ими будут управлять вещи оказываются вместе. Это кажется удобным пока их 10 штук, но становится болью когда у вас большой проект - деление на модули просто теряется. Если у вас есть константы, которые вы хотите менять между релизами - окей, кладите вместе. Или вообще положите в конфиг. А всё что касается специфики реализации конкретных частей - оставьте в них. Нет никакого смысла класть вместе константу NOT_FOUND=404, список полномочий администратора и перевод текста "не найдено" на китайский.
Enum - это вообще не про константы. Это про тип у которого есть фиксированный набор вариантов. То что там есть value - удобно в определнных случаях, но вообще не отражает его суть. Идея Enum в том, что если в каком-то месте объект может иметь несколько вариантов, которые обрабатываются по разному, то вместо магических значений вы сразу фиксируете тип с перечислением значений и фиксируете смысл каждого его названием. Value тут чисто случайно, его надо использовать с осторожность, в основном enum нужен именно чтобы проверять `obj is MyEnum.SMTH`
С логированием вы тоже немного промахнулись. Сам по себе dictConfig это ок, но он нужен не для получения экзмпляра logger, он нужен для однокркатной настройки всего logging. Дальше логгеры получайте через
logging.getLogger, как правило удобнее сделатьgetLogger(__name__), но в редких случаях может быть удобна другая иерархия. В любом случае, настройка логгеров и получение - две разные вещи, не смешивайте!!!А ещё обработкой refresh токенов и access токенов должны заниматься разные сервисы (authorization server и resource server)
Нормальная инкапсуляиция - выделение интерфейсов, когда вы просто заявляете что есть, а об остальном потребитель ни сном ни духом. Все эти "private" в языках наследников c++ - от бедности, когда технтчески понадобилось светить все внутренности потребителю класса и не надо проводить с ними параллели и пытаться повторить.
Рекомендую начать с PEP 1: https://peps.python.org/pep-0001/
А потом обратить внимание на PEP 0: https://peps.python.org/pep-0000/
И мой любимый PEP 404: https://peps.python.org/pep-0404/
Ерунда, напишите код, нарушающий все возможные архитектурные принципы, где каждая фича размазана по всей кодовой базе, где компоненты не существуют принципиально и ни о какой зоне отвественности не идет речь.
Архитектурные границы и правила организации кода - это как раз способ не держать в конетксте всё и уметь быстро найти. Нарушьте это и ваша нейросеть будет страдать так же как человек.
А пожалуйста, расскажите про "низкокачественные места", очень хочу послушать
Хотелось бы чтобы доменный слой можно было организовывать исходя из потребностей конкретного домена, а натягивать на примитивы фреймворка. Например, почему бы не существовать операциям, затрагивающим несколько агрегатов. И куда делись все дополнительные адаптеры, доменные сервисы и стратегии которые мы тоже хотим инжектировать? А как насчет приложений которые не имеют постоянного стейта в бд? Много вопросов, не надо превращать DDD в CRUD
А можно, пожалуйста, не тащить в домен фреймворки?
В пет проекте у меня покрытие 93%. Какой же это кайф рефакторить. Я на днях взял и переписал значительный кусок и просто следил что все тесты прошли. Если бы у меня их не было, я не знаю как бы с этой задачей справился - очень много вещей стреляло, о которых я уже даже не помнил