И массовое народное недовольство всегда может использовать одна из группировок в элите
использовать - может, но эта группировка должна:
Быть достаточно сильной - иначе её с лёгкостью сомнут, примеров масса.
Видеть в интересах народа для себя позитивную возможность, а не угрозу.
В данном случае в проигрыше своей страны в гонке ИИ ни одна серьёзная часть элиты никакой возможности не увидит. Максимум, что может случиться - популистские обещания после выборов серьёзно заняться этим вопросом, создать парламентскую комиссию, провести открытые слушания и т.д. и т.п.
Иными словами - выразят глубочайшую озабоченность, пообещают обо всём позаботиться, а тех, кто будет требовать радикального пересмотра общественного договора, обзовут популистами, иностранными агентами и врагами нашей великой страны.
Это всё - очень американская точка зрения на происходящее, статья точно не переводная?
В мире есть сильно больше одной страны и конкуренцию между странами и их элитами никто отменить не может.
Ни в одной крупной демократической стране, включая США, у народа нет законных способов влиять на курс, выбранный элитами. Выборы позволяют повлиять на то, какая именно часть элиты поведёт страну в выбранную элитами сторону, не более того.
Сильный ИИ потенциально даёт огромные конкурентные преимущества в самых разных сферах - военной, научной, управленческой, экономической. Даже если его отменят в одной стране, это просто даст другим возможность её обойти. Это классическая диллема заключённого.
Поэтому ИИ продолжит развиваться и его продолжат внедрять в разные сферы деятельности. И да, это окажет самое серьёзное давление на рынок труда. И чем сильнее он будет становиться, тем меньше будет значить голос “простого” человека - ведь он станет ненужен ни в качестве наёмного сотрудника, ни в качестве рекрута, ни в качестве мелкого бизнесмена (последнее - из-за отсутствия платежеспособного спроса).
Могут ли жители, скажем, США, организованно взбунтоваться против внедрения ИИ? Нет, не могут, потому что информационное пространство, включая социальные сети и мессенджеры, контролируется отнюдь не жителями, а совсем наоборот. Законных методов остановить этот процесс у них нет, потому что “право собственности священно”.
Но даже если у них всё получится, что это им даст? Просто технологическое и экономическое отставание от тех стран, где этого не произойдёт.
Пролетарии всех стран, объединяйтесь? Не думаю, что это сработает. Доказано опытным путём, так сказать.
поразительно, насколько много людей застряли в фазе отрицания…
да, есть много поводов говорить о проблемах с разработкой на базе 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?
Конкретно этот минус поставил я. Разумеется, не за цитату, а за попытку выдать своё, кхм, странное понимание этой цитаты за аргумент в споре.
"Transactions should not cross aggregate boundaries." - транзакции не должны ПЕРЕСЕКАТЬ границы агрегатов, т.е. не должны их нарушать, не должны разрушать защиту инвариантов, которую создают агрегаты. Агрегат должен меняться по принципу всё-или-ничего.
Фаулер не говорил, что транзакции не могут ОБЪЕДИНЯТЬ сохранения разных агрегатов, это было бы полной глупостью, не правда ли? Какой в этом, даже чисто теоретически, был бы смысл?
Пока архивирали аккаунт, кто-то позвонил, счетчик числа пропущенных звонков на аккаунте обновился, транзакция упала, т.к. не прошла оптимистичная конкурентность по аккаунту.
Извините, конечно, но вы упорно путаете тёплое с мягким.
Ошибки конкурентного обновления точно также могут встречаться и внутри одного агрегата - да сплошь и рядом. Это тут вообще непричём, абстракции совершенно разного уровня.
Агрегаты защищают инварианты, а не спасают от конкурентных обновлений :)
Жизнь заставит вас пересмотреть свои взгляды, когда наиграетесь в DDD на локалхосте и начнёте масштабироваться.
Ну да, я же, убогий, за 20+ лет практики реальных-то приложений не видел...
В этом месте корабль DDD затонул из-за дырявой абстракции
А причём тут вообще DDD? А он тут совершенно и непричём. Вообще никакого отношения к вопросу не имеет.
Хотите сохранять данные в одной транзакции, чтобы не возиться с eventual consistency? DDD вам это позволяет сделать. Сталкиваетесь с редкими ошибками конкурентного обновления? DDD вам не мешает использовать retry. Не можете себе позволить сохранять несколько сущностей в одной транзакции (из-за конкурентных обновлений или хранения данных в разных storage)? DDD вас полностью поддерживает.
И что значит "репозитории в принципе не нужны"? Если я, допустим, не следую DDD, то мне репозитории не пригодятся?
если так, тогда вам не стоит лезть со своим пониманием того, что такое репозиторий, в разговоры про DDD считайте это созвучным словом на другом языке
Их много. Их сложно назвать и их незачем выносить в отдельный именованый тип. в доменной логике или нет?
если вы не выделяете доменную логику, то вы в этом разговоре напрасно тратите и своё и моё время
просто для примера - в рамках стратегического паттерна DDD про Единый Язык прямо утверждается, что в разных поддоменах один и тот же термин может и будет иметь разные значения
я не знаю, сумел ли Эванс зарегистрировать торговую марку на термин Repository, на самом деле, но лично мне хотелось бы, конечно, запретить его использовать тем, кто DDD не практикует :) но это так, лирика
Например что такое QueryHandlers в Application слое и чем они отличаются от DbQueryHandlers в инфраструктуре?
QueryHandlers ~= CommandHandler DbQueryHandlers - метод исполнения эффективных запросов на чтение QueryHandlers скорее всего будут использовать DbQueryHandlers, но это не точно
А что за Application Services и чем отличаются от domain сервисов?
классы-сервисы могут быть и в application-слое, почему нет? логики в этом слое вообще немало, просто это не та логика, которую вы бы захотели обсуждать с дедком 82 лет от роду, который называет компьютеры ЭВМ
Что скажите насчет UseCase и UserStory?
Скажу, что это прекрасные термины, не имеющие особого отношения к тактическим паттернам DDD
А чем это отличается от спецификации?
Тем, что вам не приходится изобретать свой язык, конструировать его выражения в одном месте и деконструировать его в другом, я полагаю :)
И при этом у вас не возникает дублирование, но метод IsVip по прежнему - часть вашего доменного слоя.
Как вы создаете сущность из DTO, которое пришло из контроллера?
в application layer, в обработчике события, вызываю фабричный метод и сохраняю транзакцию
опять же, см. раздел про Read Model, некоторые методы применения Value Object, на мой взгляд, вполне допустимы
И да, я бы на первое место всё-таки ставил агрегат, а репозиторий — это его скромный слуга.
это чисто методологический вопрос - как лучше объяснять
мне кажется, что объяснить смысл агрегата без понимания (или, ещё хуже, с неправильном пониманием) репозитория - намного сложнее, но это просто моё мнение
я совершенно не разбираюсь в 1С и ничего не могу сказать по этому поводу. интуитивно - очень в этом сомневаюсь, но моя компетенция в этом вопросе строго нулевая
использовать - может, но эта группировка должна:
Быть достаточно сильной - иначе её с лёгкостью сомнут, примеров масса.
Видеть в интересах народа для себя позитивную возможность, а не угрозу.
В данном случае в проигрыше своей страны в гонке ИИ ни одна серьёзная часть элиты никакой возможности не увидит. Максимум, что может случиться - популистские обещания после выборов серьёзно заняться этим вопросом, создать парламентскую комиссию, провести открытые слушания и т.д. и т.п.
Иными словами - выразят глубочайшую озабоченность, пообещают обо всём позаботиться, а тех, кто будет требовать радикального пересмотра общественного договора, обзовут популистами, иностранными агентами и врагами нашей великой страны.
скорее, автоматизирует и не рухнет в процессе, но да, что-то в этом роде поэтому этот процесс и невозможно остановить
нуууу… это несерьёзно…
Это всё - очень американская точка зрения на происходящее, статья точно не переводная?
В мире есть сильно больше одной страны и конкуренцию между странами и их элитами никто отменить не может.
Ни в одной крупной демократической стране, включая США, у народа нет законных способов влиять на курс, выбранный элитами. Выборы позволяют повлиять на то, какая именно часть элиты поведёт страну в выбранную элитами сторону, не более того.
Сильный ИИ потенциально даёт огромные конкурентные преимущества в самых разных сферах - военной, научной, управленческой, экономической. Даже если его отменят в одной стране, это просто даст другим возможность её обойти. Это классическая диллема заключённого.
Поэтому ИИ продолжит развиваться и его продолжат внедрять в разные сферы деятельности. И да, это окажет самое серьёзное давление на рынок труда. И чем сильнее он будет становиться, тем меньше будет значить голос “простого” человека - ведь он станет ненужен ни в качестве наёмного сотрудника, ни в качестве рекрута, ни в качестве мелкого бизнесмена (последнее - из-за отсутствия платежеспособного спроса).
Могут ли жители, скажем, США, организованно взбунтоваться против внедрения ИИ? Нет, не могут, потому что информационное пространство, включая социальные сети и мессенджеры, контролируется отнюдь не жителями, а совсем наоборот. Законных методов остановить этот процесс у них нет, потому что “право собственности священно”.
Но даже если у них всё получится, что это им даст? Просто технологическое и экономическое отставание от тех стран, где этого не произойдёт.
Пролетарии всех стран, объединяйтесь? Не думаю, что это сработает. Доказано опытным путём, так сказать.
поразительно, насколько много людей застряли в фазе отрицания…
да, есть много поводов говорить о проблемах с разработкой на базе 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?
э-э-э-э-э... ну, спасибо, нет
Конкретно этот минус поставил я. Разумеется, не за цитату, а за попытку выдать своё, кхм, странное понимание этой цитаты за аргумент в споре.
"Transactions should not cross aggregate boundaries." - транзакции не должны ПЕРЕСЕКАТЬ границы агрегатов, т.е. не должны их нарушать, не должны разрушать защиту инвариантов, которую создают агрегаты. Агрегат должен меняться по принципу всё-или-ничего.
Фаулер не говорил, что транзакции не могут ОБЪЕДИНЯТЬ сохранения разных агрегатов, это было бы полной глупостью, не правда ли? Какой в этом, даже чисто теоретически, был бы смысл?
Извините, конечно, но вы упорно путаете тёплое с мягким.
Ошибки конкурентного обновления точно также могут встречаться и внутри одного агрегата - да сплошь и рядом. Это тут вообще непричём, абстракции совершенно разного уровня.
Агрегаты защищают инварианты, а не спасают от конкурентных обновлений :)
Ну да, я же, убогий, за 20+ лет практики реальных-то приложений не видел...
А причём тут вообще DDD? А он тут совершенно и непричём. Вообще никакого отношения к вопросу не имеет.
Хотите сохранять данные в одной транзакции, чтобы не возиться с eventual consistency? DDD вам это позволяет сделать.
Сталкиваетесь с редкими ошибками конкурентного обновления? DDD вам не мешает использовать retry.
Не можете себе позволить сохранять несколько сущностей в одной транзакции (из-за конкурентных обновлений или хранения данных в разных storage)? DDD вас полностью поддерживает.
Вообще никакой проблемы нет.
если так, тогда вам не стоит лезть со своим пониманием того, что такое репозиторий, в разговоры про DDD
считайте это созвучным словом на другом языке
если вы не выделяете доменную логику, то вы в этом разговоре напрасно тратите и своё и моё время
просто для примера - в рамках стратегического паттерна DDD про Единый Язык прямо утверждается, что в разных поддоменах один и тот же термин может и будет иметь разные значения
я не знаю, сумел ли Эванс зарегистрировать торговую марку на термин Repository, на самом деле, но лично мне хотелось бы, конечно, запретить его использовать тем, кто DDD не практикует :)
но это так, лирика
QueryHandlers ~= CommandHandler
DbQueryHandlers - метод исполнения эффективных запросов на чтение
QueryHandlers скорее всего будут использовать DbQueryHandlers, но это не точно
классы-сервисы могут быть и в application-слое, почему нет?
логики в этом слое вообще немало, просто это не та логика, которую вы бы захотели обсуждать с дедком 82 лет от роду, который называет компьютеры ЭВМ
Скажу, что это прекрасные термины, не имеющие особого отношения к тактическим паттернам DDD
Тем, что вам не приходится изобретать свой язык, конструировать его выражения в одном месте и деконструировать его в другом, я полагаю :)
И при этом у вас не возникает дублирование, но метод IsVip по прежнему - часть вашего доменного слоя.
в application layer, в обработчике события, вызываю фабричный метод и сохраняю транзакцию
опять же, см. раздел про Read Model, некоторые методы применения Value Object, на мой взгляд, вполне допустимы
это чисто методологический вопрос - как лучше объяснять
мне кажется, что объяснить смысл агрегата без понимания (или, ещё хуже, с неправильном пониманием) репозитория - намного сложнее, но это просто моё мнение
я совершенно не разбираюсь в 1С и ничего не могу сказать по этому поводу.
интуитивно - очень в этом сомневаюсь, но моя компетенция в этом вопросе строго нулевая