Вообще, полагать, что вас обязательно должны взять в какую-то команду/проект, потому что у вас достаточный уровень крутости, это примерно как полагать, что некий конкретный молодой человек обязательно должен жениться на конкретной девушке, потому что она красивая (и потому что ей этого хочется).
Есть целая теория построение функциональных команд (и не одна). Её мало кто знает и применяет на практике, но даже так она прорывается на интуитивном уровне. Есть стили лидерства, есть уже занятые роли в команде, просто человеческие симпатии/антипатии.
Ну не хочется этому конкретному руководителю с вами работать. Потому что вы рыжий, а его в детстве унижал рыжий сосед по подъезду. И он по опыту знает, что вы для него будете постоянным генератором стресса - так чего ради ему себя через колено ломать, если можно нанять блондина (или даже блондинку) с примерно такими же скиллами?
Средняя температура по больнице, кстати, сейчас вообще никакого значения не имеет и ни о чём не говорит. ИИ очень легко использовать неправильно и достаточно сложно - правильно, процессы совершенно не отработаны, всё в процессе и быстро меняется.
Например, если в проекте нет качественного memory bank-а, то какой вам ещё вайбкодинг? Будет сплошной нейрослоп. А ведь многие и слова такого не знают, не говоря уже то том, чтобы вкладываться в его развитие и поддержку. Нужны качественные skill-ы, нужно управлять контекстом, нужно чётко разделять фазы постановки, планирования, реализации, проверки / review.
Меня лично интересует только опыт топ 10% по успешности внедрения именно ИИ, зачем обращать внимание на результаты тех, кого из под палки заставили писать код в Cursor, что у них может быть хорошего? Их опыт годится только для самоутешения, дескать, “этот пузырь скоро лопнет, надо просто перетерпеть”.
Например, я под большим впечатлением от того, как codex делает mr review и ищет причины ошибок в сложных кодовых базах. Его очень удобно подряжать проводить эксперименты по оптимизации кода с доказательной базой. Отлично справляется с рефакторингом средней сложности. Очень хорош в генерации идей.
С кодингом чего-то сложного справляется пока на 3+ (для senior-а), требуется постоянный контроль. Но по сравнению с тем, что было ещё года полтора назад - несравненно лучше.
Собственно, основная проблема сейчас именно в соблазне нагенерить кучу кода одним запросом, а с проблемами оставить разбираться других. Т.е., в сущности, организационная. Но таких товарищей и до ИИ хватало, просто сейчас у них радиус поражения вырос на пару порядков.
“верующего в ИИ” - оскорбления в разговорах с коллегами для вас норма? Вы и в офисе так общаетесь?
Как именно я, будучи наёмным сотрудником, должен вам показывать “финансовый результат”-то? Результат “выше ожиданий” я показывал и до ИИ и сейчас, а зарплатную вилку никто не отменял.
Брать дополнительную работу на стороне? Спасибо, не нуждаюсь, да и рынок сейчас не тот.
Во времена, предшествовавшие краху доткомов, расплодилось множество сайтов и Java-программистов. Это всё рухнуло со страшной силой и впервые появились шуточки про “code html for food”.
Но это не вина java и не доказательство того, что html - никому не нужный отстой.
ИИ - это очень круто, в том числе - прямо сейчас. В правильных, прямых руках, разумеется. А в кривых руках ИИ позволяет делать всякую фигню в сто раз быстрее, чем когда бы то ни было.
И массовое народное недовольство всегда может использовать одна из группировок в элите
использовать - может, но эта группировка должна:
Быть достаточно сильной - иначе её с лёгкостью сомнут, примеров масса.
Видеть в интересах народа для себя позитивную возможность, а не угрозу.
В данном случае в проигрыше своей страны в гонке ИИ ни одна серьёзная часть элиты никакой возможности не увидит. Максимум, что может случиться - популистские обещания после выборов серьёзно заняться этим вопросом, создать парламентскую комиссию, провести открытые слушания и т.д. и т.п.
Иными словами - выразят глубочайшую озабоченность, пообещают обо всём позаботиться, а тех, кто будет требовать радикального пересмотра общественного договора, обзовут популистами, иностранными агентами и врагами нашей великой страны.
Это всё - очень американская точка зрения на происходящее, статья точно не переводная?
В мире есть сильно больше одной страны и конкуренцию между странами и их элитами никто отменить не может.
Ни в одной крупной демократической стране, включая США, у народа нет законных способов влиять на курс, выбранный элитами. Выборы позволяют повлиять на то, какая именно часть элиты поведёт страну в выбранную элитами сторону, не более того.
Сильный ИИ потенциально даёт огромные конкурентные преимущества в самых разных сферах - военной, научной, управленческой, экономической. Даже если его отменят в одной стране, это просто даст другим возможность её обойти. Это классическая диллема заключённого.
Поэтому ИИ продолжит развиваться и его продолжат внедрять в разные сферы деятельности. И да, это окажет самое серьёзное давление на рынок труда. И чем сильнее он будет становиться, тем меньше будет значить голос “простого” человека - ведь он станет ненужен ни в качестве наёмного сотрудника, ни в качестве рекрута, ни в качестве мелкого бизнесмена (последнее - из-за отсутствия платежеспособного спроса).
Могут ли жители, скажем, США, организованно взбунтоваться против внедрения ИИ? Нет, не могут, потому что информационное пространство, включая социальные сети и мессенджеры, контролируется отнюдь не жителями, а совсем наоборот. Законных методов остановить этот процесс у них нет, потому что “право собственности священно”.
Но даже если у них всё получится, что это им даст? Просто технологическое и экономическое отставание от тех стран, где этого не произойдёт.
Пролетарии всех стран, объединяйтесь? Не думаю, что это сработает. Доказано опытным путём, так сказать.
поразительно, насколько много людей застряли в фазе отрицания…
да, есть много поводов говорить о проблемах с разработкой на базе LLM как надуманных, так и вполне реальных
но на каждую историю про то, как LLM написала ужасный код, предложила ужасное решение или удалила продовую базу, можно привести десяток историй о том, как это сделали живые программисты
у меня тоже есть коллекция любимых баек про то, как айтишники (включая меня) творили лютую, отчаянную дичь, в которую даже сложно поверить, и что это доказывает?
ИИ - мощнейший усилитель ваших процессов, компетенций и тараканов в вашей голове, а не волшебная палочка его нужно использовать правильно. Нужно использовать. Правильно использовать.
Сами LLM совершенствуются, тулы совершенствуются, подходы совершенствуются. И ничего из этого совершенствоваться не прекратит. И по мере этого совершенствования потребность в людях, зарабатывающих посредством перевода спецификации в код будет уменьшаться в пересчёте на одну фичу, тут ничего не поделаешь.
Те, кто сейчас отказываются нанимать джунов (которых в РФ обычно называют миддлами), исходят из не обязательно верного, но прекрасно обоснованного предположения, что через 5 лет (а тем более через 10) им и синьоры тоже будут без надобности.
А нужны будут скорее миксы из продакта и аналитика для ведения нескольких проектов.
При этом микросервис/модуль станет минимальной единицей в разработке ПО. Человекочитаемого кода для них даже генерироваться не будет, за ненадобностью.
И это - технопессимисты. Технооптимисты предполагают, что через 10 лет ИИ будет делать любую интеллектуальную работу лучше любого человека. Вообще без исключений в обе стороны.
Фантастика? Вы знаете много примеров того, что ИИ сейчас не толком работает? Ага, всё верно. Просто поговорим об этом через 5 лет, ок? А сейчас, в 2026, ИИ пишет код и решает проблемы в нём лучше примерно 60-70 процентов программистов, с которыми я когда-либо работал. При правильном подходе, разумеется.
Выделяем сложный модуль в отдельный проект, назначаем на него рок-звезду, даём ему возможность подобрать себе коллегу, который “будет тебе помогать” и “закрывать тикеты, пока ты в отпуске”.
Выделяем этих двоих в отдельную команду, с отдельными code-review и митами. Тем самым снимается львиная доля проблем с токсичностью в команде.
Ещё желательно натравить в качестве reviewer-а этого проекта (ведь “он так важен”), вашего архитектора/staff, которого рок-звезда не может просто заткнуть, как недостаточно компетентного, чтобы ему что-то объяснять или доказывать. Его задача - добиться от рок-звезды внутренней архитектуры модуля, которая для понимания не требует ни быть её автором, ни даже просто выдающихся компетенций (хотя требуемые компетенции по прежнему могут значительно превышать компетенции вашей команды, но это отдельный вопрос).
Дальше получается вилка - если рок-звезда и правда неадекват (скорее всего с серьёзным выгоранием), то его можно уволить после того, как “помощник” в целом разберётся в модуле, а в новую команду добрать сильных специалистов. Откуда бюджет на расширение? Ну, если рок-звезде приходится работать по 10+ часов в день, значит либо количественная сложность проблемы недооценивается бизнесом, либо ваша рок-звезда не такая уж и звезда, а просто старый, усталый рокер, а качественная сложность проблемы ему не по зубам.
Ну а если вы просто наняли человека, технический уровень которого сильно превышает уровень остальной команды, то внезапно окажется, что новая команда продуктивна, в ней нормальная рабочая атмосфера и т.д. и т.п. Ну, отлично, получилась кузница кадров, а проблема в запрягании лебедя, рака и щуки куда-то не туда.
Альтернатива - внутренний перевод либо звезды, либо руководителя команды, так как текущий с ситуацией, очевидно, не справляется.
В HR-тусовке ходят не менее фееричные байки про кандидатов it-шников.
Грустная правда (которую понимаешь с возрастом) в том, что это всё не про роли, а про людей, как и всегда.
Проблема не в мужчинах/женщинах, чиновниках/народе, бумерах/зумерах, буржуях/пролетариях и т.д. и т.п. Проблема всегда в людях.
И именно поэтому проблема эта никогда не решится, каждое новое поколение будет косячить везде, где это только возможно, и, временами, там, где, казалось бы, накосячить даже в теории невозможно. Как и всегда.
Можно только становиться лучше самому и стараться выбирать себе окружение (от друзей до страны) получше (в широком смысле). Остальное не работает.
Я писал об этом несколько лет назад и остаюсь при своём мнении сейчас. Ситуацию с разработкой с помощью нейросетей нужно рассматривать через призму байки про пруд, постепенно зарастающий ряской.
Да, 2-3 года назад наш пруд был заросшим только на 3%. Но ряска продолжала распространятся всё это время, продолжает сейчас и продолжит в будущем.
Похоже, сейчас пруд зарос на 30%-40%. На этом этапе многие вайбкодят пет-проекты, передовые инженеры и некоторые компании переходят на 100% генерацию кода агентами, топы готовятся к полной трансформации it-отделов.
Агенты генерируют чушь? Часть кейсов не понимают и не могут закрыть? Плохо справляются с большими кодовыми базами? Не вопрос, давайте вернёмся к этому вопросу этой осенью. А потом ещё раз следующей весной.
А ещё потом пруд окажется заросшим на 100%. С AI-friendly architecture и specification-driven-development, где за человеком не останется даже code review, только контроль логики приёмо-сдаточных тестов. И так ли принципиально, когда именно это случится - через год, два или пять?
Принципиальный вопрос же на самом деле в другом - каким будет мир, в котором интеллектуальной работы в современном понимании не останется вовсе, потому что AI пишет симфонии, проводит научные изыскания и диагностирует заболевания лучше, чем 95% людей? А потом 98%...
Кмк, тут есть два подхода - юридический и человеческий.
Юридический предполагает, что вы защищаете свою компанию от возможного иска. Тут советоваться нужно строго с профильными юристами, мнение it-шников не имеет абсолютно никакого значения.
Человеческий подход - пойти на сайт, который у вас там крутится, найти там контакты компании, которой он принадлежит, связаться с ними по этим контактам и попросить разъяснить ситуацию. А после разъяснения - предъявить что-то, что сойдёт за доказательство, о чём лучше, опять же, спросить юристов, ибо защита вашей компании в приоритете. Так вы решите вопрос по существу.
Даже Вернон, при всей его любви к eventual consistency, вовсе не запрещает сохранять несколько агрегатов в одной транзакции, напротив, рекомендует это делать в некоторых случаях.
Microsoft, в свою очередь, в той самой статье, которую вы привели, упоминает о том, что разные проектировщики делают это по разному, но сами они предпочитают именно мой вариант (воплощённый в их основном архитектурном примере, к слову).
Так делаю я, так делают многие другие.
Но, разумеется, признать свою неправоту - выше ваших сил. И вы продолжаете настаивать на том, что "However, there is nothing preventing you from committing modifications to two or more Aggregates in a single atomic database transaction. " означает прямой запрет это делать в дурацком ddd.
Ну и смысл с вами разговаривать, коллега? Ладно бы вы могли предложить работающую альтернативу, так ведь нет, вы настаиваете на том, что ddd - нерабочая хрень. Ну да, ddd в трактовке таких, как вы, действительно нерабочая хрень. Именно поэтому я и потратил время на написание этой публикации.
более того выше вы отстаивали, что данное решение нерабочее.
Ну, это уже совсем ни в какие ворота... как бы я мог отстаивать такую глупость, если сам так постоянно делаю? В статье чётко проведена грань между доменными событиями и интеграционными (последние могут быть in-process, тут нет никакой проблемы).
Я вам уже объяснял, что дешёвым это изменение может не быть. Потребуется изменить и UI/UX
вы объяснили неправильно
Да, если кто-то облажался настолько эпично, как вы описали, то да, конечно придётся.
Но на каждый такой случай приходится десяток случаев попроще, когда ничего подобного не получается. И жёсткая позиция "каждый агрегат строго в своей транзакции" заставляет вас иметь дело со всеми негативными последствиями eventual consistency на ровном месте, когда нести эти издержки не нужно.
При этом проблему конкурентных обновлений вы таким образом всё равно не решаете (хотя и ослабляете), потому что они прекрасно могут случиться и в одном агрегате тоже.
Поэтому, разумеется, надо проявлять гибкость и опираться на здравый смысл. Именно это и позволяет сделать связка из доменных событий, обрабатываемых в единой транзакции, и интеграционных событий, обрабатываемых в отдельной транзакции.
Это и есть причина, почему агрегаты дробят на более маленькие - снизить вероятность конкурентного обновления, повысить вероятность успешной транзакции.
одна из - да, но не основная, конечно
Агрегаты защищают свои инварианты, инварианты других агрегатов не должны влиять на успешность транзакции.
это ваше, странное, неправильное мнение, я не знаю, откуда вы его взяли это решать application слою, в зависимости от ситуации, агрегата это не никак касается, это не его дело и вообще не дело доменного слоя
дело доменного слоя в этом вопросе - доменное событие сгенерировать, но на этом - всё
Сам по себе без оркестрации апликейшен слоем собрать какой-то мало-мальски полезные процесс не получится.
ну, даже если у вас не получается, это же не значит, что не получается у других, правда? это другая парадигма и многие люди прекрасно работают в ней стоит привыкнуть и это становится очень естественно
На этом этапе тоже возникает противоречие. Типа как так, мы собрали агрегаты по требованиям бизнеса, но из-за инфраструктурного консерна вроде масштабируемости приходится менять устройство домена, путем нарезания агрегатов на более маленькие.
эммм... нет ну то есть такое тоже бывает, но, в общем случае, разумеется, нет
как вы верно сказали в начале - одной из целей разработки агрегата является желание избежать конфликтов обновления это, вроде, очевидно
конечно, ddd и агрегаты тут совершенно непричём, эта проблема в любом случае возникнет, какой методологией разработки вы бы не пользовались вода - водяная, масло - масленное
если вероятность конкурентных обновлений низка - обновляйтесь в одной транзакции и будет вам и простота и эффективность и счастье если вероятность конкурентных обновлений существенна - разрывайте транзакцию
ошиблись? исправляйте ошибку в application layer, доменный слой при этом останется незатронут
However, there is nothing preventing you from committing modifications to two or more Aggregates in a single atomic database transaction. You might choose to use this approach in cases that you know will succeed but use eventual consistency for all others.
да, но моё странное понимание - работает на практике, в реальных проектах
ваше странное понимание, по вашему же признанию, не работает и работать не должно
и теперь, внимание, следите за руками, вы настаиваете на том, что правильное понимание - это ваше понимание, то самое, в котором ddd - это неработающая, неприменимая на практике чушь
соответственно я, по вашему настойчивому убеждению, должен отказаться от работающей методики в пользу принципиально неработоспособной, просто потому, что иначе я неправильно понимаю ddd?
Вообще, полагать, что вас обязательно должны взять в какую-то команду/проект, потому что у вас достаточный уровень крутости, это примерно как полагать, что некий конкретный молодой человек обязательно должен жениться на конкретной девушке, потому что она красивая (и потому что ей этого хочется).
Есть целая теория построение функциональных команд (и не одна). Её мало кто знает и применяет на практике, но даже так она прорывается на интуитивном уровне. Есть стили лидерства, есть уже занятые роли в команде, просто человеческие симпатии/антипатии.
Ну не хочется этому конкретному руководителю с вами работать. Потому что вы рыжий, а его в детстве унижал рыжий сосед по подъезду. И он по опыту знает, что вы для него будете постоянным генератором стресса - так чего ради ему себя через колено ломать, если можно нанять блондина (или даже блондинку) с примерно такими же скиллами?
Работа она не только про работу же.
Средняя температура по больнице, кстати, сейчас вообще никакого значения не имеет и ни о чём не говорит. ИИ очень легко использовать неправильно и достаточно сложно - правильно, процессы совершенно не отработаны, всё в процессе и быстро меняется.
Например, если в проекте нет качественного memory bank-а, то какой вам ещё вайбкодинг? Будет сплошной нейрослоп. А ведь многие и слова такого не знают, не говоря уже то том, чтобы вкладываться в его развитие и поддержку. Нужны качественные skill-ы, нужно управлять контекстом, нужно чётко разделять фазы постановки, планирования, реализации, проверки / review.
Меня лично интересует только опыт топ 10% по успешности внедрения именно ИИ, зачем обращать внимание на результаты тех, кого из под палки заставили писать код в Cursor, что у них может быть хорошего? Их опыт годится только для самоутешения, дескать, “этот пузырь скоро лопнет, надо просто перетерпеть”.
Например, я под большим впечатлением от того, как codex делает mr review и ищет причины ошибок в сложных кодовых базах. Его очень удобно подряжать проводить эксперименты по оптимизации кода с доказательной базой. Отлично справляется с рефакторингом средней сложности. Очень хорош в генерации идей.
С кодингом чего-то сложного справляется пока на 3+ (для senior-а), требуется постоянный контроль. Но по сравнению с тем, что было ещё года полтора назад - несравненно лучше.
Собственно, основная проблема сейчас именно в соблазне нагенерить кучу кода одним запросом, а с проблемами оставить разбираться других. Т.е., в сущности, организационная. Но таких товарищей и до ИИ хватало, просто сейчас у них радиус поражения вырос на пару порядков.
“верующего в ИИ” - оскорбления в разговорах с коллегами для вас норма? Вы и в офисе так общаетесь?
Как именно я, будучи наёмным сотрудником, должен вам показывать “финансовый результат”-то? Результат “выше ожиданий” я показывал и до ИИ и сейчас, а зарплатную вилку никто не отменял.
Брать дополнительную работу на стороне? Спасибо, не нуждаюсь, да и рынок сейчас не тот.
нет но моя жизнь стала заметно проще и приятнее
я его успешно применяю каждый день и таких людей очень много
“нет успешных примеров” это какая-то странная религия
Во времена, предшествовавшие краху доткомов, расплодилось множество сайтов и Java-программистов. Это всё рухнуло со страшной силой и впервые появились шуточки про “code html for food”.
Но это не вина java и не доказательство того, что html - никому не нужный отстой.
ИИ - это очень круто, в том числе - прямо сейчас. В правильных, прямых руках, разумеется. А в кривых руках ИИ позволяет делать всякую фигню в сто раз быстрее, чем когда бы то ни было.
использовать - может, но эта группировка должна:
Быть достаточно сильной - иначе её с лёгкостью сомнут, примеров масса.
Видеть в интересах народа для себя позитивную возможность, а не угрозу.
В данном случае в проигрыше своей страны в гонке ИИ ни одна серьёзная часть элиты никакой возможности не увидит. Максимум, что может случиться - популистские обещания после выборов серьёзно заняться этим вопросом, создать парламентскую комиссию, провести открытые слушания и т.д. и т.п.
Иными словами - выразят глубочайшую озабоченность, пообещают обо всём позаботиться, а тех, кто будет требовать радикального пересмотра общественного договора, обзовут популистами, иностранными агентами и врагами нашей великой страны.
скорее, автоматизирует и не рухнет в процессе, но да, что-то в этом роде поэтому этот процесс и невозможно остановить
нуууу… это несерьёзно…
Это всё - очень американская точка зрения на происходящее, статья точно не переводная?
В мире есть сильно больше одной страны и конкуренцию между странами и их элитами никто отменить не может.
Ни в одной крупной демократической стране, включая США, у народа нет законных способов влиять на курс, выбранный элитами. Выборы позволяют повлиять на то, какая именно часть элиты поведёт страну в выбранную элитами сторону, не более того.
Сильный ИИ потенциально даёт огромные конкурентные преимущества в самых разных сферах - военной, научной, управленческой, экономической. Даже если его отменят в одной стране, это просто даст другим возможность её обойти. Это классическая диллема заключённого.
Поэтому ИИ продолжит развиваться и его продолжат внедрять в разные сферы деятельности. И да, это окажет самое серьёзное давление на рынок труда. И чем сильнее он будет становиться, тем меньше будет значить голос “простого” человека - ведь он станет ненужен ни в качестве наёмного сотрудника, ни в качестве рекрута, ни в качестве мелкого бизнесмена (последнее - из-за отсутствия платежеспособного спроса).
Могут ли жители, скажем, США, организованно взбунтоваться против внедрения ИИ? Нет, не могут, потому что информационное пространство, включая социальные сети и мессенджеры, контролируется отнюдь не жителями, а совсем наоборот. Законных методов остановить этот процесс у них нет, потому что “право собственности священно”.
Но даже если у них всё получится, что это им даст? Просто технологическое и экономическое отставание от тех стран, где этого не произойдёт.
Пролетарии всех стран, объединяйтесь? Не думаю, что это сработает. Доказано опытным путём, так сказать.
поразительно, насколько много людей застряли в фазе отрицания…
да, есть много поводов говорить о проблемах с разработкой на базе LLM как надуманных, так и вполне реальных
но на каждую историю про то, как LLM написала ужасный код, предложила ужасное решение или удалила продовую базу, можно привести десяток историй о том, как это сделали живые программисты
у меня тоже есть коллекция любимых баек про то, как айтишники (включая меня) творили лютую, отчаянную дичь, в которую даже сложно поверить, и что это доказывает?
ИИ - мощнейший усилитель ваших процессов, компетенций и тараканов в вашей голове, а не волшебная палочка его нужно использовать правильно. Нужно использовать. Правильно использовать.
Сами LLM совершенствуются, тулы совершенствуются, подходы совершенствуются. И ничего из этого совершенствоваться не прекратит. И по мере этого совершенствования потребность в людях, зарабатывающих посредством перевода спецификации в код будет уменьшаться в пересчёте на одну фичу, тут ничего не поделаешь.
Те, кто сейчас отказываются нанимать джунов (которых в РФ обычно называют миддлами), исходят из не обязательно верного, но прекрасно обоснованного предположения, что через 5 лет (а тем более через 10) им и синьоры тоже будут без надобности.
А нужны будут скорее миксы из продакта и аналитика для ведения нескольких проектов.
При этом микросервис/модуль станет минимальной единицей в разработке ПО. Человекочитаемого кода для них даже генерироваться не будет, за ненадобностью.
И это - технопессимисты. Технооптимисты предполагают, что через 10 лет ИИ будет делать любую интеллектуальную работу лучше любого человека. Вообще без исключений в обе стороны.
Фантастика? Вы знаете много примеров того, что ИИ сейчас не толком работает? Ага, всё верно. Просто поговорим об этом через 5 лет, ок? А сейчас, в 2026, ИИ пишет код и решает проблемы в нём лучше примерно 60-70 процентов программистов, с которыми я когда-либо работал. При правильном подходе, разумеется.
Выделяем сложный модуль в отдельный проект, назначаем на него рок-звезду, даём ему возможность подобрать себе коллегу, который “будет тебе помогать” и “закрывать тикеты, пока ты в отпуске”.
Выделяем этих двоих в отдельную команду, с отдельными code-review и митами. Тем самым снимается львиная доля проблем с токсичностью в команде.
Ещё желательно натравить в качестве reviewer-а этого проекта (ведь “он так важен”), вашего архитектора/staff, которого рок-звезда не может просто заткнуть, как недостаточно компетентного, чтобы ему что-то объяснять или доказывать. Его задача - добиться от рок-звезды внутренней архитектуры модуля, которая для понимания не требует ни быть её автором, ни даже просто выдающихся компетенций (хотя требуемые компетенции по прежнему могут значительно превышать компетенции вашей команды, но это отдельный вопрос).
Дальше получается вилка - если рок-звезда и правда неадекват (скорее всего с серьёзным выгоранием), то его можно уволить после того, как “помощник” в целом разберётся в модуле, а в новую команду добрать сильных специалистов. Откуда бюджет на расширение? Ну, если рок-звезде приходится работать по 10+ часов в день, значит либо количественная сложность проблемы недооценивается бизнесом, либо ваша рок-звезда не такая уж и звезда, а просто старый, усталый рокер, а качественная сложность проблемы ему не по зубам.
Ну а если вы просто наняли человека, технический уровень которого сильно превышает уровень остальной команды, то внезапно окажется, что новая команда продуктивна, в ней нормальная рабочая атмосфера и т.д. и т.п. Ну, отлично, получилась кузница кадров, а проблема в запрягании лебедя, рака и щуки куда-то не туда.
Альтернатива - внутренний перевод либо звезды, либо руководителя команды, так как текущий с ситуацией, очевидно, не справляется.
В HR-тусовке ходят не менее фееричные байки про кандидатов it-шников.
Грустная правда (которую понимаешь с возрастом) в том, что это всё не про роли, а про людей, как и всегда.
Проблема не в мужчинах/женщинах, чиновниках/народе, бумерах/зумерах, буржуях/пролетариях и т.д. и т.п. Проблема всегда в людях.
И именно поэтому проблема эта никогда не решится, каждое новое поколение будет косячить везде, где это только возможно, и, временами, там, где, казалось бы, накосячить даже в теории невозможно. Как и всегда.
Можно только становиться лучше самому и стараться выбирать себе окружение (от друзей до страны) получше (в широком смысле). Остальное не работает.
Я писал об этом несколько лет назад и остаюсь при своём мнении сейчас. Ситуацию с разработкой с помощью нейросетей нужно рассматривать через призму байки про пруд, постепенно зарастающий ряской.
Да, 2-3 года назад наш пруд был заросшим только на 3%. Но ряска продолжала распространятся всё это время, продолжает сейчас и продолжит в будущем.
Похоже, сейчас пруд зарос на 30%-40%. На этом этапе многие вайбкодят пет-проекты, передовые инженеры и некоторые компании переходят на 100% генерацию кода агентами, топы готовятся к полной трансформации it-отделов.
Агенты генерируют чушь? Часть кейсов не понимают и не могут закрыть? Плохо справляются с большими кодовыми базами? Не вопрос, давайте вернёмся к этому вопросу этой осенью. А потом ещё раз следующей весной.
А ещё потом пруд окажется заросшим на 100%. С AI-friendly architecture и specification-driven-development, где за человеком не останется даже code review, только контроль логики приёмо-сдаточных тестов. И так ли принципиально, когда именно это случится - через год, два или пять?
Принципиальный вопрос же на самом деле в другом - каким будет мир, в котором интеллектуальной работы в современном понимании не останется вовсе, потому что AI пишет симфонии, проводит научные изыскания и диагностирует заболевания лучше, чем 95% людей? А потом 98%...
Кмк, тут есть два подхода - юридический и человеческий.
Юридический предполагает, что вы защищаете свою компанию от возможного иска. Тут советоваться нужно строго с профильными юристами, мнение it-шников не имеет абсолютно никакого значения.
Человеческий подход - пойти на сайт, который у вас там крутится, найти там контакты компании, которой он принадлежит, связаться с ними по этим контактам и попросить разъяснить ситуацию. А после разъяснения - предъявить что-то, что сойдёт за доказательство, о чём лучше, опять же, спросить юристов, ибо защита вашей компании в приоритете. Так вы решите вопрос по существу.
Ну, т.е., иными словами.
Даже Вернон, при всей его любви к eventual consistency, вовсе не запрещает сохранять несколько агрегатов в одной транзакции, напротив, рекомендует это делать в некоторых случаях.
Microsoft, в свою очередь, в той самой статье, которую вы привели, упоминает о том, что разные проектировщики делают это по разному, но сами они предпочитают именно мой вариант (воплощённый в их основном архитектурном примере, к слову).
Так делаю я, так делают многие другие.
Но, разумеется, признать свою неправоту - выше ваших сил. И вы продолжаете настаивать на том, что "However, there is nothing preventing you from committing modifications to two or more Aggregates in a single atomic database transaction. " означает прямой запрет это делать в дурацком ddd.
Ну и смысл с вами разговаривать, коллега? Ладно бы вы могли предложить работающую альтернативу, так ведь нет, вы настаиваете на том, что ddd - нерабочая хрень. Ну да, ddd в трактовке таких, как вы, действительно нерабочая хрень. Именно поэтому я и потратил время на написание этой публикации.
Ну, это уже совсем ни в какие ворота... как бы я мог отстаивать такую глупость, если сам так постоянно делаю? В статье чётко проведена грань между доменными событиями и интеграционными (последние могут быть in-process, тут нет никакой проблемы).
вы объяснили неправильно
Да, если кто-то облажался настолько эпично, как вы описали, то да, конечно придётся.
Но на каждый такой случай приходится десяток случаев попроще, когда ничего подобного не получается. И жёсткая позиция "каждый агрегат строго в своей транзакции" заставляет вас иметь дело со всеми негативными последствиями eventual consistency на ровном месте, когда нести эти издержки не нужно.
При этом проблему конкурентных обновлений вы таким образом всё равно не решаете (хотя и ослабляете), потому что они прекрасно могут случиться и в одном агрегате тоже.
Поэтому, разумеется, надо проявлять гибкость и опираться на здравый смысл. Именно это и позволяет сделать связка из доменных событий, обрабатываемых в единой транзакции, и интеграционных событий, обрабатываемых в отдельной транзакции.
одна из - да, но не основная, конечно
это ваше, странное, неправильное мнение, я не знаю, откуда вы его взяли
это решать application слою, в зависимости от ситуации, агрегата это не никак касается, это не его дело и вообще не дело доменного слоя
дело доменного слоя в этом вопросе - доменное событие сгенерировать, но на этом - всё
ну, даже если у вас не получается, это же не значит, что не получается у других, правда?
это другая парадигма и многие люди прекрасно работают в ней
стоит привыкнуть и это становится очень естественно
эммм... нет
ну то есть такое тоже бывает, но, в общем случае, разумеется, нет
как вы верно сказали в начале - одной из целей разработки агрегата является желание избежать конфликтов обновления
это, вроде, очевидно
конечно, ddd и агрегаты тут совершенно непричём, эта проблема в любом случае возникнет, какой методологией разработки вы бы не пользовались
вода - водяная, масло - масленное
если вероятность конкурентных обновлений низка - обновляйтесь в одной транзакции и будет вам и простота и эффективность и счастье
если вероятность конкурентных обновлений существенна - разрывайте транзакцию
ошиблись? исправляйте ошибку в application layer, доменный слой при этом останется незатронут
Domain-Driven Design Distilled
Vaughn Vernon
да, но моё странное понимание - работает на практике, в реальных проектах
ваше странное понимание, по вашему же признанию, не работает и работать не должно
и теперь, внимание, следите за руками, вы настаиваете на том, что правильное понимание - это ваше понимание, то самое, в котором ddd - это неработающая, неприменимая на практике чушь
соответственно я, по вашему настойчивому убеждению, должен отказаться от работающей методики в пользу принципиально неработоспособной, просто потому, что иначе я неправильно понимаю ddd?
э-э-э-э-э... ну, спасибо, нет