Я программист. Еще я решил лишний раз проверить и скачал книгу Эрика Эванса, который считается основателем DDD и поискал там слова model, behavior и the code. В тех или иных местах встречаются фразы, которые говорят о том, что доменная модель в итоге преобразуется в программный код и там внутри должно быть поведение.
Knowledge rich model. The objects had behavior and enforced rules. The model wasn’t just a data schema
and the code is refactored to reflect the deeper model
И если диаграммы - это все же ближе к проектированию, а не коду, то вот скрин с примером кода rich объекта с поведением внутри.
Так что я не могу согласиться, что DDD это только про бизнес дизайн и архитектуру, если даже основатель приводит примеры кода с богатой моделью.
И то, как я закодил свой тренировочный микросервис - это все же в какой-то мере DDD, только оно ужасно тормозит.
А почему оно тормозит? Потому что согласно DDD я должен оперировать rich сущностью, восстановленной из хранилища, а бизнес логика, бизнес правила и валидация должны быть внутри этой сущности. В итоге это превращается в следующую цепочку
Начало транзакции
Сетевой вызов №1
Дергаем БД и получаем строку с блокировкой
Сетевой вызов №2
ORM маппит строку в объект
Бизнес-логика, валидация, обновление состояния
Кидаем exception, если все плохо
ORM мапит объект в запрос на обновление
Дергаем БД и делаем update строки
Сетевой вызов №3
Дергаем БД и делаем insert строки
Сетевой вызов №4
Завершаем транзакцию и отпускаем блокировку
Сетевой вызов №5
А вот как это выглядит, если отказаться от DDD (от программной части) и перенести в хранимку
Вызов хранимой процедуры с параметрами
Сетевой вызов №1
Начало транзакции
Делаем update строки с блокировкой
Делаем insert строки
Делаем select (аки бизнес-правило / валидация)
Кидаем exception, если все плохо
Завершаем транзакцию
Я тут относительно недавно общался в коментах по поводу DDD. Как пробрасывать 100500 полей в сущность при создании - через конструктор или еще как. Раньше я использовал анемичную модель.
В общем запилил я тренировочный микросервис, который условно резервирует товар на складе. По DDD, логика в сущностях, ORM, и все такое. Ну а так как резерв товара - это блокировки в любом случае в том или ином виде, подготовил пару вариантов - на оптимистичной и пессимистичной блокировке (SELECT ... FOR UPDATE).
Но надо же проверить нагрузочным тестом, тем более что в реальном проекте на проде - это проблема.
Короче этот DDD выдал 20 rps для варианта с пессимистичной блокировкой.
Плюнул, перенес логику в хранимки, чтобы не тащить все это по сети из БД на сервер - стало 420 rps. Хотя пожалуй код из хранимки можно поместить как есть в репозиторий (там три запроса - update, insert и select). Но это все равно не станет "логикой внутри сущности".
Так что теперь мой главный вывод про DDD - это 100 раз подумать, прежде чем использовать DDD.
В крупных системах миллионы методов, на каждый атрибут/аннотацию не повесишь. Лучше делать еще более централизованное решение. Например в .NET через прокси объекты и интерсепторы (библиотеки castle)
Мало того, в статье это описано сумбурно - логи и телеметрия это же разные вещи.
В реально работающих продуктах в логах на 146% нужен контекст и собственно запрос/ответ. Иначе ничего непонятно. Но писать вообще все - может быть дорого.
А вот этот самописный атрибут/аннотация в статье - это больше похоже на именно что телеметрию. Чтобы фиксировать время входа и выхода из методов по стеку.
Но опять же - не знаю как в Java и других, но в .NET Core это делается через специальные активити. Причем сама платформа их активно использует и ASP.NET и ORM (entity framework) уже пишут их. Остается только добавить их на уровне бизнес слоя для детализации.
И все равно в конце надо писать в телеметрию текст запроса к базе данных, чтобы узнать какой именно запрос тормозит.
По ощущениям от прочитанного - самыми адекватными показался макдональдс. Не стали сразу рубить все на корню, а сделали пилотный запуск. Собственно так и надо делать.
По разному конечно бывает, зависит от многих факторов - стек (хотя самую большую зп я как раз видел у пхп программиста на Хабра карьере 1.2 млн), место работы, отношение к сотрудникам, собственный опыт и подача себя.
И я не один такой был - мои бывшие и текущие коллеги на тот момент (человек 5-7), просто рандомные люди из интернета.
Были и не единичный случаи, в 2015-2017 - зарубежная удаленка, upwork и всякие такие варианты, $4-6к для сениоров. К 2019 году подтянулись и внутренние российские вакансии. Их тоже стало заметное количество на общепринятых ресурсах.
Сейчас судя по сайтам и тг-каналам наоборот - в публичных вакансиях на сениоров я все чаще вижу 250.
Зарплаты 300-400 у программистов были еще в 2015 - 2019 годах, с тех пор прошло от 6 до 10 лет. Сейчас они тоже 400. Поправьте в статье «рост» на «отрицательный рост»
Вы мне напомнили как я ходил на школьные олимпиады по физике и астрономии, и я теперь замечаю сходство.
Суть подхода: в голове есть некий кэш существующих знаний, формулы всякие и если память хорошая, то константы. В олимпиадных задачах надо из этого кэша достать подходящий набор знаний. Для простых задач это можно сделать за один проход. Для сложных за несколько и скомпоновать их.
Приведу пример, больше 20 лет прошло, а помню до сих пор, очень она мне понравилась своей постановкой. Задача: луноход катит по поверхности маленького спутника, с заданной массой и диаметром, с какой максимальной скоростью он может ехать? Решение: достать из кэша знаний формулу первой космической, подставить цифры и посчитать. Эту задачу можно усложнить, указав диаметр и среднюю плотность породы или даже оставить только диаметр и написать, что скальные породы, без пустот. Тогда понадобиться еще дополнительно 1-2 формулы из кэша, чтобы диаметр и плотность преобразовать в массу.
В программировании такой же подход, только вместо формул в кэше надо держать базовые алгоритмы и структуры данных. Правда там еще закодить надо. Это дольше, чем посчитать формулу. Но в реальных задачах - программист не держит все знания в голове. Под рукой есть гугл, чтобы восстановить этот кэш.
А вот «придумывать» - это например придумать формулу первой космической с нуля за время олимпиады и потом использовать ее в решении искомой задачи. Это совсем другой уровень. Всякие Ньютоны и Эйнштейны бились за это на протяжении столетий.
И что интересно - негатива к школьным олимпиадам у меня не было, наоборот. Я знал чего ожидать, были интересные постановки задач. Время давали правда не 30-60 минут на задачу, а пол дня - день. По астрономии я например два раза доходил до областной - там вообще было два дня решения задач.
А вот все эти компании с алго-собесами - не могут четко сказать чего ожидать и критерии оценки. Ну поучитесь тогда у школьных олимпиад что ли. Не надо этого пафоса, скажите прямо - у нас олимпиадные задачи, все задачи могут быть решены с использованием вот этого списка алгоритмов и вот этого списка структур данных. Можно или нельзя использовать гугл / чат гпт / сниппеты кода (потому что алгоритмы заранее все известны смысл тратить время на набивание кода на клавиатуре). И критерии оценки - например, количество пройденных тест кейсов.
Я в яндекс не пробовал, но зато собеседовался в другую компанию с алго-собесами (не в России, но и не FAANG). Там прям с порога пафосно заявляли, что CEO сам бывший программист и ищут достойных кандидатов и давали две задачи - medium и hard, но формат - как бы непрерывное домашнее задание на 3 часа, с записью видео, запретом на чат гпт и все такое.
Так вот, я никогда не задрачивал на лит код (так, глянул пару раз easy). Но прикол в том, что medium я все таки смог решить за 3 часа как раз (все тесты кейсы прошли, даже самые закорючные и разумеется всех тест кейсов там не показывали).
А что в итоге - отказ. Почему? Потому что не решил все задачи. Серьезно? Встает вопрос - а что тогда вообще проверяют?
Много раз слышал "мы проверяем то как кандидат решает задачу". Ну вроде бы логично - видно как кандидат решает задачу, которую он НИ РАЗУ не решал. Я вполне допускаю, что это реальная ситуация в компаниях типа гугла или яндекса, когда ответа нет (собственно) в гугле/яндексе и на стек оверфлоу. Ну так тогда именно мой случай отлично показал, что я способен решать НЕЗНАКОМЫЕ МНЕ задачи на определенном уровне, своей головой, без гугления и чата гпт. Но отказ.
А раз я не прошел, выходит проверяют совсем не это. Да, получается тупо решение олимпиадных задачек, на время. Но, чтобы решать такие задачи именно на время достаточно выучить базовые алгоритмы решений ИМЕННО ТАКИХ ЗАДАЧ. Или еще проще - на лит коде есть раздел по компаниям. Просто прорешать их все и вызубрить. Все, прошел.
И вишенка на торте. Во-первых там 80% индусятины. Во-вторых зарплата у них меньше, чем у меня текущая. То есть надо порвать жопу, чтобы удовлетворить набор шизофренических требований CEO, а потом за меньшую зарплату разгребать индуский говнокод. Нахрен такое не надо.
-----
А вот реальная история, связанная с алгоритмами. Довелось мне однажды кодить алгоритм по сглаживанию GPS трека. Так вот собес на алгоритмы и реальная работа и рядом не стояли. В моем случае мне повезло - такую задачу уже решали и я нашел несколько источников, как и на стек оверфлоу, так и обзорные статьи по алгоритмам (что лучше, что хуже, что может подойти), и даже нашел научную статью на сотню страниц со всеми математическими выкладками, примерами, статистикой погрешности и так далее.
Так вот, чтобы на самом деле хорошо сделать эту задачу - надо прочитать и осознать подобные научные работы, проанализировать и принять решение. Это реально трудно и ресурсоемко. В тот раз я не стал этого делать, я бы эту статью только месяц читал бы и разбирал. Я начал как бы с нуля своим умом и за ТРИ ДНЯ (а не а 30-60 минут) выдал более-менее работающее и удовлетворяющее решение со списком, что и как еще можно попробовать улучшить. Там на самом деле ничего заумного я не делал, просто компоновал различные походы очистки данных, существующие алгоритмы, экспериментировал и на каждой итерации выбирал то, что больше нравилось, или откатывался с предыдущему варианту.
А потом я еще представил - ну вот работал бы я в каком-нибудь гугле и что если бы не было научной работы и всего того, что я нашел? А собственно ничего. Для начала надо было бы родить такую научную работу. Таки тогда вопрос - это все еще собес на программиста или Перельмана?
https://habr.com/ru/articles/965812/comments/#comment_29108838
Вот цитаты и скрин из книги Эрика Эванса - у него это объекты, классы с поведением внутри.
Я программист. Еще я решил лишний раз проверить и скачал книгу Эрика Эванса, который считается основателем DDD и поискал там слова model, behavior и the code. В тех или иных местах встречаются фразы, которые говорят о том, что доменная модель в итоге преобразуется в программный код и там внутри должно быть поведение.
И если диаграммы - это все же ближе к проектированию, а не коду, то вот скрин с примером кода rich объекта с поведением внутри.
Так что я не могу согласиться, что DDD это только про бизнес дизайн и архитектуру, если даже основатель приводит примеры кода с богатой моделью.
И то, как я закодил свой тренировочный микросервис - это все же в какой-то мере DDD, только оно ужасно тормозит.
А почему оно тормозит? Потому что согласно DDD я должен оперировать rich сущностью, восстановленной из хранилища, а бизнес логика, бизнес правила и валидация должны быть внутри этой сущности. В итоге это превращается в следующую цепочку
А вот как это выглядит, если отказаться от DDD (от программной части) и перенести в хранимку
Я тут относительно недавно общался в коментах по поводу DDD. Как пробрасывать 100500 полей в сущность при создании - через конструктор или еще как. Раньше я использовал анемичную модель.
В общем запилил я тренировочный микросервис, который условно резервирует товар на складе. По DDD, логика в сущностях, ORM, и все такое. Ну а так как резерв товара - это блокировки в любом случае в том или ином виде, подготовил пару вариантов - на оптимистичной и пессимистичной блокировке (SELECT ... FOR UPDATE).
Но надо же проверить нагрузочным тестом, тем более что в реальном проекте на проде - это проблема.
Короче этот DDD выдал 20 rps для варианта с пессимистичной блокировкой.
Плюнул, перенес логику в хранимки, чтобы не тащить все это по сети из БД на сервер - стало 420 rps. Хотя пожалуй код из хранимки можно поместить как есть в репозиторий (там три запроса - update, insert и select). Но это все равно не станет "логикой внутри сущности".
Так что теперь мой главный вывод про DDD - это 100 раз подумать, прежде чем использовать DDD.
В крупных системах миллионы методов, на каждый атрибут/аннотацию не повесишь. Лучше делать еще более централизованное решение. Например в .NET через прокси объекты и интерсепторы (библиотеки castle)
Мало того, в статье это описано сумбурно - логи и телеметрия это же разные вещи.
В реально работающих продуктах в логах на 146% нужен контекст и собственно запрос/ответ. Иначе ничего непонятно. Но писать вообще все - может быть дорого.
А вот этот самописный атрибут/аннотация в статье - это больше похоже на именно что телеметрию. Чтобы фиксировать время входа и выхода из методов по стеку.
Но опять же - не знаю как в Java и других, но в .NET Core это делается через специальные активити. Причем сама платформа их активно использует и ASP.NET и ORM (entity framework) уже пишут их. Остается только добавить их на уровне бизнес слоя для детализации.
И все равно в конце надо писать в телеметрию текст запроса к базе данных, чтобы узнать какой именно запрос тормозит.
По мне так - хороший объем данных, хотелось бы больше графиков и в динамике
А почему вы предложили на 30% меньше?
По ощущениям от прочитанного - самыми адекватными показался макдональдс. Не стали сразу рубить все на корню, а сделали пилотный запуск. Собственно так и надо делать.
Вот и ответ.
В 2007 - 2009 у меня было 20-25 в госухе, в регионе, повысить никак не могли.
В начале 2010 нашел удаленку на Москву, стало 50, потом в 2011 повысили до 60. Дальше отказались.
Я просто нашел новую работу в начале 2012 на 80. Через год в 2013 повысили до 100, дальше отказались.
Я нашел новую на 150 в начале 2014. И так далее.
Это же общеизвестная фигня - хочешь больше зп - меняй работу. Хотя пожалуй в 2025 это уже не работает 😅
Совсем печаль...
Я и не говорил про 2013 год, я сказал 2015 - 2019.
Я не шиз, не грубите.
По разному конечно бывает, зависит от многих факторов - стек (хотя самую большую зп я как раз видел у пхп программиста на Хабра карьере 1.2 млн), место работы, отношение к сотрудникам, собственный опыт и подача себя.
И я не один такой был - мои бывшие и текущие коллеги на тот момент (человек 5-7), просто рандомные люди из интернета.
Были и не единичный случаи, в 2015-2017 - зарубежная удаленка, upwork и всякие такие варианты, $4-6к для сениоров. К 2019 году подтянулись и внутренние российские вакансии. Их тоже стало заметное количество на общепринятых ресурсах.
Сейчас судя по сайтам и тг-каналам наоборот - в публичных вакансиях на сениоров я все чаще вижу 250.
Зарплаты 300-400 у программистов были еще в 2015 - 2019 годах, с тех пор прошло от 6 до 10 лет. Сейчас они тоже 400. Поправьте в статье «рост» на «отрицательный рост»
Всякие Илоны Маски и изобретатели тоже читали фантастику 40-50-60 ых годов. И просто пытаются воплотить это в жизнь.
Вы мне напомнили как я ходил на школьные олимпиады по физике и астрономии, и я теперь замечаю сходство.
Суть подхода: в голове есть некий кэш существующих знаний, формулы всякие и если память хорошая, то константы. В олимпиадных задачах надо из этого кэша достать подходящий набор знаний. Для простых задач это можно сделать за один проход. Для сложных за несколько и скомпоновать их.
Приведу пример, больше 20 лет прошло, а помню до сих пор, очень она мне понравилась своей постановкой. Задача: луноход катит по поверхности маленького спутника, с заданной массой и диаметром, с какой максимальной скоростью он может ехать? Решение: достать из кэша знаний формулу первой космической, подставить цифры и посчитать. Эту задачу можно усложнить, указав диаметр и среднюю плотность породы или даже оставить только диаметр и написать, что скальные породы, без пустот. Тогда понадобиться еще дополнительно 1-2 формулы из кэша, чтобы диаметр и плотность преобразовать в массу.
В программировании такой же подход, только вместо формул в кэше надо держать базовые алгоритмы и структуры данных. Правда там еще закодить надо. Это дольше, чем посчитать формулу. Но в реальных задачах - программист не держит все знания в голове. Под рукой есть гугл, чтобы восстановить этот кэш.
А вот «придумывать» - это например придумать формулу первой космической с нуля за время олимпиады и потом использовать ее в решении искомой задачи. Это совсем другой уровень. Всякие Ньютоны и Эйнштейны бились за это на протяжении столетий.
И что интересно - негатива к школьным олимпиадам у меня не было, наоборот. Я знал чего ожидать, были интересные постановки задач. Время давали правда не 30-60 минут на задачу, а пол дня - день. По астрономии я например два раза доходил до областной - там вообще было два дня решения задач.
А вот все эти компании с алго-собесами - не могут четко сказать чего ожидать и критерии оценки. Ну поучитесь тогда у школьных олимпиад что ли. Не надо этого пафоса, скажите прямо - у нас олимпиадные задачи, все задачи могут быть решены с использованием вот этого списка алгоритмов и вот этого списка структур данных. Можно или нельзя использовать гугл / чат гпт / сниппеты кода (потому что алгоритмы заранее все известны смысл тратить время на набивание кода на клавиатуре). И критерии оценки - например, количество пройденных тест кейсов.
Я в яндекс не пробовал, но зато собеседовался в другую компанию с алго-собесами (не в России, но и не FAANG). Там прям с порога пафосно заявляли, что CEO сам бывший программист и ищут достойных кандидатов и давали две задачи - medium и hard, но формат - как бы непрерывное домашнее задание на 3 часа, с записью видео, запретом на чат гпт и все такое.
Так вот, я никогда не задрачивал на лит код (так, глянул пару раз easy). Но прикол в том, что medium я все таки смог решить за 3 часа как раз (все тесты кейсы прошли, даже самые закорючные и разумеется всех тест кейсов там не показывали).
А что в итоге - отказ. Почему? Потому что не решил все задачи. Серьезно? Встает вопрос - а что тогда вообще проверяют?
Много раз слышал "мы проверяем то как кандидат решает задачу". Ну вроде бы логично - видно как кандидат решает задачу, которую он НИ РАЗУ не решал. Я вполне допускаю, что это реальная ситуация в компаниях типа гугла или яндекса, когда ответа нет (собственно) в гугле/яндексе и на стек оверфлоу. Ну так тогда именно мой случай отлично показал, что я способен решать НЕЗНАКОМЫЕ МНЕ задачи на определенном уровне, своей головой, без гугления и чата гпт. Но отказ.
А раз я не прошел, выходит проверяют совсем не это. Да, получается тупо решение олимпиадных задачек, на время. Но, чтобы решать такие задачи именно на время достаточно выучить базовые алгоритмы решений ИМЕННО ТАКИХ ЗАДАЧ. Или еще проще - на лит коде есть раздел по компаниям. Просто прорешать их все и вызубрить. Все, прошел.
И вишенка на торте. Во-первых там 80% индусятины. Во-вторых зарплата у них меньше, чем у меня текущая. То есть надо порвать жопу, чтобы удовлетворить набор шизофренических требований CEO, а потом за меньшую зарплату разгребать индуский говнокод. Нахрен такое не надо.
-----
А вот реальная история, связанная с алгоритмами. Довелось мне однажды кодить алгоритм по сглаживанию GPS трека. Так вот собес на алгоритмы и реальная работа и рядом не стояли. В моем случае мне повезло - такую задачу уже решали и я нашел несколько источников, как и на стек оверфлоу, так и обзорные статьи по алгоритмам (что лучше, что хуже, что может подойти), и даже нашел научную статью на сотню страниц со всеми математическими выкладками, примерами, статистикой погрешности и так далее.
Так вот, чтобы на самом деле хорошо сделать эту задачу - надо прочитать и осознать подобные научные работы, проанализировать и принять решение. Это реально трудно и ресурсоемко. В тот раз я не стал этого делать, я бы эту статью только месяц читал бы и разбирал. Я начал как бы с нуля своим умом и за ТРИ ДНЯ (а не а 30-60 минут) выдал более-менее работающее и удовлетворяющее решение со списком, что и как еще можно попробовать улучшить. Там на самом деле ничего заумного я не делал, просто компоновал различные походы очистки данных, существующие алгоритмы, экспериментировал и на каждой итерации выбирал то, что больше нравилось, или откатывался с предыдущему варианту.
А потом я еще представил - ну вот работал бы я в каком-нибудь гугле и что если бы не было научной работы и всего того, что я нашел? А собственно ничего. Для начала надо было бы родить такую научную работу. Таки тогда вопрос - это все еще собес на программиста или Перельмана?
Попробовал нагрузочные тесты на своем эталонном микросервисе с аллокацией товара для заказа. Разница примерно в два раза.
MySql docker
MySql docker --tmpfs /var/lib/mysql:rw,size=8192m
Ой, да, не туда :)
Не очень понятно, как у вас время выполнения упало с десятков минут до секунд.
Нет разницы где запускать БД - на реальном сервере или в докере, она все равно ходит на жесткий диск. Или вы там tmpfs используете?
Не очень понятно, как у вас время выполнения упало с десятков минут до секунд.
Нет разницы где запускать БД - на реальном сервере или в докере, она все равно ходит на жесткий диск. Или вы там tmpfs используете?