Так то в DDD много всего. И в книгах про DDD есть примеры диаграмм, кода на тех или иных языках программирования (там классы, ООП, и все такое). Концептуально DDD построено на том, что оно независимо от всего остального (и БД в том числе)
И следовательно, требуется загружать состояние агрегатов и сущностей из хранилища в память компьютера (это можно сделать как через ORM так и другими способами), потом производить некоторые операции и затем сохранять новое состояние в БД. Это отвязывает DDD от конкретного хранилища и позволяет писать быстрые юнит тесты на доменные объекты и бизнес-логику.
Но как раз тут и начинаются тормоза. И все подобные статьи поверхностны и не отвечают на неудобные вопросы. Ну а хранимые процедуры на то и называются процедурами - это по сути анемичная модель (в виде таблиц) и отдельно "код с бизнес-логикой".
Тесты которые нельзя запускать параллельно (например с использованием буфера обмена) - запускать последовательно
Остальные разделить физически (отдельные докеры, отдельные БД) или логически (каждый юзер видит свои данные). Но тут не были упомянуты мульти-тенантные системы и тесты в рамках транзакций БД
Что-то как-то попадаются устаревшие вещи - очередь за забором опять появилась и на российском и на зарубежном рынке.
Рекрутеры не умеют в отбор
Ну допустим, а кто-нибудь проводил аналогичное исследование, но среди экспертов, а не рекрутеров? Сколько у них показало вероятность, намного лучше чем монетка?
профильное образование никак не повышало шансы кандидатов проходить техническое собеседование и получать оффер
Верно, но так же верно и другое - после того как кандидат вышел на работу разница между человеком с вышкой и без вышки есть. Благо у нас появились всякие курсы и всякие повара / курьеры / таксисты их проходят, потом пытаются устроится на работу, у некоторых даже получается, а вот потом начинаются проблемы с укладыванием в голове сложных систем и взаимосвязей. Да и в зарубежных вакансиях попадалось типа "вышка + 4 года опыта" или "без вышки + 8 лет опыта".
Я же обращу ваше внимание на такой нюанс. Большинство ATS не сравнивают новые резюме с присланными ранее. Потому, если вы хотите повысить шансы на прохождение этого криво работающего забора, после получения автоматического отказа создавайте новую заявку с резюме в новом формате.
Подтверждаю, сам так делал и со второго раза доходил до человека. То есть если ATS система в первый раз не пропустила, то люди об этом не знают. Только надо еще мелким шрифтом белым текстом на белом фоне догнать резюме до 70-80% совпадения.
А сейчас он по сути интерпретатор js + глобальные переменные + шаблоны/подстановки + моки + cli
Все это довольно глючное, но позволяет реально сделать автоматизацию тестирования API. Особенно, если еще прикрутить утилиту которая генерит API к бд по ее схеме.
И его коллекции не совместимы с git. Вот недавно только появилась тема у них.
Для поддержки и развития такой дуры нужны люди и деньги.
Но если рассматривать постман как curl - да, можно сказать что они зажрались.
Сейчас есть некоторые исследования в области квантовой запутанности, что по идее может привести к изобретению мгновенной связи и будет межзведный телеграф с азбукой Морзе. А это в свою очередь может повлиять на межзвездный финансовый рынок 🫠
На самом деле поднадоели такие статьи. Все довольно поверхностно. И они не отвечают на неудобные вопросы.
Я когда на более ооп-шном C# попробовал сделать DDD - там столько вопросов возникло. В реализации на Go из статьи они тоже есть. Вот например фабричный метод, в заказе может быть 100500 всяких бизнесовых полей - это вы все их пихать будете как параметры? То есть на каждый чих менять контракт? А не задолбаетесь?
Почему в таких статьях DDD рассматривается в отрыве от производительности? Автор, вы понимаете, что DDD со своим "восстановить сущность из хранилища и потом запускать на ней бизнес логику" - это жутко медленная штука? И если потребуется выжать больше 50 rps без деградации с ростом нагрузки, то придется переходить на нативный SQL / хранимки с логикой. А это уже ни разу не DDD.
А еще интересно было бы сравнить с mongo db или любой другой бд, заточенной под хранение json
Нет, не путаю.
Так то в DDD много всего. И в книгах про DDD есть примеры диаграмм, кода на тех или иных языках программирования (там классы, ООП, и все такое). Концептуально DDD построено на том, что оно независимо от всего остального (и БД в том числе)
И следовательно, требуется загружать состояние агрегатов и сущностей из хранилища в память компьютера (это можно сделать как через ORM так и другими способами), потом производить некоторые операции и затем сохранять новое состояние в БД. Это отвязывает DDD от конкретного хранилища и позволяет писать быстрые юнит тесты на доменные объекты и бизнес-логику.
Но как раз тут и начинаются тормоза. И все подобные статьи поверхностны и не отвечают на неудобные вопросы. Ну а хранимые процедуры на то и называются процедурами - это по сути анемичная модель (в виде таблиц) и отдельно "код с бизнес-логикой".
А где среди всего этого переход на нативный sql и бизнес логику в хранимках, потому что этот ваш DDD дико тормозит?
Вот такая
У нас мульти-тенантная b2b, логическое разделение, транзакции, тесты на ui только начинаем, так что с буфером обмена пока не столкнулись.
Line
TLDR
Тесты которые нельзя запускать параллельно (например с использованием буфера обмена) - запускать последовательно
Остальные разделить физически (отдельные докеры, отдельные БД) или логически (каждый юзер видит свои данные). Но тут не были упомянуты мульти-тенантные системы и тесты в рамках транзакций БД
А как так вышло, что сократили, если не секрет? Российская или зарубежная компания?
Нет, не обольщайтесь, в северной америке, очередь в магазине на кассу - это не queue
Ведущий программист после института? 21 летний сениор? Расскажите как так вышло, жутко интересно.
И сейчас, к сожалению, не лучшее время для возвращения.
Напишите потом статью на хабр, интересно что и как у вас выйдет
А за что уволили, если не секрет?
Что-то как-то попадаются устаревшие вещи - очередь за забором опять появилась и на российском и на зарубежном рынке.
Ну допустим, а кто-нибудь проводил аналогичное исследование, но среди экспертов, а не рекрутеров? Сколько у них показало вероятность, намного лучше чем монетка?
Верно, но так же верно и другое - после того как кандидат вышел на работу разница между человеком с вышкой и без вышки есть. Благо у нас появились всякие курсы и всякие повара / курьеры / таксисты их проходят, потом пытаются устроится на работу, у некоторых даже получается, а вот потом начинаются проблемы с укладыванием в голове сложных систем и взаимосвязей. Да и в зарубежных вакансиях попадалось типа "вышка + 4 года опыта" или "без вышки + 8 лет опыта".
Подтверждаю, сам так делал и со второго раза доходил до человека. То есть если ATS система в первый раз не пропустила, то люди об этом не знают. Только надо еще мелким шрифтом белым текстом на белом фоне догнать резюме до 70-80% совпадения.
Postman раньше был как curl
А сейчас он по сути интерпретатор js + глобальные переменные + шаблоны/подстановки + моки + cli
Все это довольно глючное, но позволяет реально сделать автоматизацию тестирования API. Особенно, если еще прикрутить утилиту которая генерит API к бд по ее схеме.
И его коллекции не совместимы с git. Вот недавно только появилась тема у них.
Для поддержки и развития такой дуры нужны люди и деньги.
Но если рассматривать постман как curl - да, можно сказать что они зажрались.
Сейчас есть некоторые исследования в области квантовой запутанности, что по идее может привести к изобретению мгновенной связи и будет межзведный телеграф с азбукой Морзе. А это в свою очередь может повлиять на межзвездный финансовый рынок 🫠
Интересно и познавательно, но в пересказе опять ничего насчет производительности.
На самом деле поднадоели такие статьи. Все довольно поверхностно. И они не отвечают на неудобные вопросы.
Я когда на более ооп-шном C# попробовал сделать DDD - там столько вопросов возникло. В реализации на Go из статьи они тоже есть. Вот например фабричный метод, в заказе может быть 100500 всяких бизнесовых полей - это вы все их пихать будете как параметры? То есть на каждый чих менять контракт? А не задолбаетесь?
Почему в таких статьях DDD рассматривается в отрыве от производительности? Автор, вы понимаете, что DDD со своим "восстановить сущность из хранилища и потом запускать на ней бизнес логику" - это жутко медленная штука? И если потребуется выжать больше 50 rps без деградации с ростом нагрузки, то придется переходить на нативный SQL / хранимки с логикой. А это уже ни разу не DDD.
3) попросить оплату тестового
Еще одна причина чтобы не делать тестовые 😅
К сожалению нет, я последний раз искал работу в 2020