В идеале наверное да (да и видно что я описался). Базово, согласен. На практике, далеко не любая инфраструктура позволяет получить SLA 99%, не любые требования могут быть реализованы так, как кто-то хочет, далеко не любую архитектуру можно реализовывать по "политическим" решениям. НФТ напрямую не определяют архитектуру, а являются вводными для принятия архитектурно-важных решений. Надеюсь, что все мы разделяем архитектуру и дизайн системы, в том смысле, что первое - это решения трудоёмкие к изменению, а второе - это все детали решения.
На мой взгляд, смысл CN - в том что если всё реализовано правильно, надёжность дело наживное до определённого момента. Я упомянул про облако, про его ИТ-услуги, про зоны доступности - на мой взгляд, это говорит о заданном вопросе до определённой степени. Хорошая вводная на эту тему в книге указанной в источнике: Облачные архитектуры: разработка устойчивых и экономичных облачных приложений | Лащевски Том, Арора Камаль, Фарр Эрик, Зонуз Пийум | 978-5-4461-1588-4
Метрики реальных проектов уже мне не показать. Да и нет в этом никакой необходимости - все крупные организации делают это одинаково - стенды нагрузочного тестирования, SLA, расследование инцидентов и т.п. Я бы сказал, что надёжность - это как раз НФТ, а не архитектура. Это требование куда больше зависит от процесса и вашей инфраструктуры. Описанное выше - это про T2M, perfomance, slalability в первую очередь.
Один из примеров описывал продукт в котором пользователи росли кратно. Закрученная пружина маркетинга далеко не сразу, но очень скачкообразно привела миллионы новых клиентов. Насколько слышал от коллег, большинство строят свою надёжность от конкретных цифр, после чего по мере роста аудитории, доступность падает, требуется пересмотр решения. Наш ответ на подобное плавающее НФТ заключался в работе над типовым микросервисом и связке его с облаком, ит-услугами, с целью формирования сценариев масштабирования.
С одной стороны, я подумаю как осветить в будущих статьях тему доступности, развивающих описанное выше. С другой стороны, мне казалось что слова CloudNative и облако говорят сами за себя - SLA, OPEX/CAPEX обычно подразумеваются (возможно это мои домыслы).
Тем самым, простите, но косвенно отсылаю вас к другим материалам на тему надёжности, которые фокусируются на методологии.
В РФ другая практика - TOGAF, карты бизнес возможностей, Корп.Модель данных; иными словами "коты и мыши". На мой взгляд, статья не раскрывает этой подоплёки, а она и содержит в себе суть того зачем нужна роль архитектора и какие формы это может принимать в разных обстоятельствах. Например, если взять банки или телекомы - это огромные департаменты, которые юзают свои фреймворки, и очень часто на практике не стремятся быть ближе к бизнесу, а становятся частью внутреннего сервиса (вопросы к пуговицам есть?). Этим самовоспроизводящимся системам не нужны ни гибкие подходы, ни DDD)) Иными словами, вряд ли есть коллективы больше 200 человек, всеобъемлюще применяющие такие подходы.
Вы же почему-то выкидываете из процесса производства часть, относящуюся к разработке, и считаете производством только производство копий
Напротив, я утверждаю, что производство будет выполнено дважды в двух формах; форма цифрового продукта отрицает в иной форме его воспроизведение для пользователя. Т.е. формально процесс производства продукта (товара/услуги) происходит в момент выполнения кода. А вот прообраз этого кода - это другая форма работы.
как агитацию простых решений, которые не требуют больших затрат.
как пропаганду сегрегации ролей в производственном процессе.
И смею думать, что авторов интересовал в этой теме только хайп. Сама же пропаганда коренится в столкновении интересов менеджера и инженера. В одном месте это формулируется как излишняя сложность технического решения, в другом как низкая квалификация программистов и инженеров, в третьем апеллируют к абсолютам. По факту, менеджер всегда преследует задачу оптимальной утилизации ресурсов. И эта статья сильно подыгрывает подобной позиции.
Вы воспроизвели мой ответ, своими словами. Ещё раз, повторю свою мысль, в доказательство непротиворечивости: форма ПО соответствует материальным условиям развития. В какой-то момент, от вашего продукта может потребоваться рост, с разделением монолита, чтобы соответствовать каким-то метрикам.
Интересная мысль про баланс. ИМХО, лиды/архитекторы/owner'ы именно для соблюдения баланса и нужны, именно в движении противоречивых интересов рождаются, выраствют, умирают все продукты)
Уважаемый собеседник, боюсь вы не правильно поняли мою аналогию. Она не в делимости на части, а в сложности применяемого решения. Внешне для пользователя и то и другое будет схоже. Но для производства смартфонов нужна очень сложная производственная база, цепочки поставок, много версий нужно выпустить. Это уже не говоря о инфраструктуре телекомов.
За такими заявлениями явно есть свои интересы!!!) Отрицать МСА - это как не пользоваться смартфоном, а только городским телефоном проводным. Любые сложные системы/подходы/продукты появляются не на ровном месте, не от гения творца, а в ходе длительного развития. Смысл MSA в том что описанные сложности решаются системно, для всего ландшафта сразу, что даёт "эффект масштаба", позволяет применять эту архитектуру. При этом, конечно, имею место предпосылки к развитию архитектуры на ландшафте. Выбор архитектуры программного обеспечения, как формы его развития, тесно связан с реализуемой функциональностью и окружающими обстоятельствами. По мере количественного роста, с одной стороны, реализованных фичей, и, с другой стороны, количества заинтересованных сторон, в движении этих внутренних и внешних факторов, форма программного обеспечения склонна изменяться, выражаясь в новой архитектуре решения. Задача гибкой архитектуры при этом: предвосхитить возможные изменения, производя наиболее адаптируемый к изменениям продукт, приносить заинтересованным сторонам продукт с наиболее высокими потребительскими качествами. Воспроизведу подобный материализм развития:
Монолитное приложение - это продукт, состоящий из нескольких слоёв или уровней, которые можно выделить логически, иногда физически:
Интерфейс;
Логика приложения;
Слой доступа к данным;
База данных.
Многие продукты и процессы начинаются именно с такой формы. По мере усложнения логики, описания всё большего количества процессов, т.е. при изменении содержания, форма также изменяется. 2. Так или иначе, по мере роста и развития приложения, возникают проблемамы монолитных архитектур:
сложность системы постоянно растет;
поддерживать ее все сложнее и сложнее;
разобраться в ней трудно — особенно если система переходила из поколения в поколение, логика - забывалась, люди уходили и приходили, а комментариев и тестов нет);
много ошибок;
мало тестов — монолит не разобрать и не протестировать, поэтому обычно есть только UI-тесты, поддержка которых обычно занимает много времени;
дорого вносить изменения;
застревание на технологиях
Однако, если приложение приносило пользу стейкхолдерам и развивалось, со временем количество пользователей/операций в системе может значительно вырасти. Появиться необходимость масштабировать систему. 3. Чтобы масштабировать систему, снизить время выхода функциональности, повысить отказоустойчивость и доступность, приходят к микросервисам и облакам.
Т.о. есть предпосылки к появлению микросервисной архитектуры: качественный рост количества фич, правок в них, потребителей.
Профсоюз как низовое движение, отстаивающее интересы коллективов - высшая форма демократии, сознательности рабочих. Вы должны способствовать развитию открытого ПО, поднимать вопрос об отмене собственности на ПО, обговаривать условия труда, но профсоюз ведущий диалог с властью про свой свечной заводик - жёлтый профсоюз.
По поводу экосистемы. Наличие/отсутствие таковой прямо коррелирует с местом страны в мир-системе капиталистической экономики. В условиях тотальной глобализации, крупные компании найдут обходные пути получения железа и софта. А если же экосистема будет реализовываться, то, с одной стороны, спонсировать это будет другой пролетарий, на которого ляжет инфляционная и налоговая нагрузка; с другой стороны, правительство может разыграть в любой момент компрадорскую карту, отказавшись от экосистемы, как уже бывало ни раз за 30 лет.
Вам бы не Мишустиным писать, а писать о том что совсем скоро ждёт всех работников IT, раскрывать методологию органайзинга, агитировать за отстаивание своих рабочих прав.
Извините, но вы так дойдете до того, что заявите про то, что было время, когда строительные архитекторы CJM проектировали.
о CJM
CJM не писали, но практику похожую на EventStorming и сбор общеупотребимого языка ВХУТЕМАС и БАУХАУС проводили, вероятно как и последующие архитекторы. На этом фото часть стенда посвящённая столетию ВХУТЕМАСА, про то как обучали студентов важности общения за заитересованными сторонами.
Если или когда найду кокретный анализ для конкретных объектов (такое было, но не всё легко отыскать), обязательно подкреплю к этому ответу.
Я не пытаюсь свою точку зрения навязать, скорее преуменьшить IT как нечто особенное. Правильно смотреть и на здания и на ПО как основной капитал бизнеса (производства). Если смотреть с этой стороны, то разница совсем уж не велика, т.к. и то и другое используется как технические возможности для обеспечения бизнес-процессов.
Для IT-архитекторов, которые «в танке» и любят сравнивать себя с зодчими:
Архитектурный раздел строительного проекта больше относится к внешней, фасадной части. В нём прорабатываются вопросы эстетики, оформления, отделки помещений и всего прочего, с этим связанного.
Вы здессь сразу сузили определение до рамок строительного проекта - корректно ли это? А кто делал проект Москвы-Сити, например? Сейчас чаще всего так и есть, но было время архитекторы проектировали районы и целые города. Сейчас архитектор - дизайнер потому, что строительство исходит не из рациональности, а из профита.
Связь явно есть, иначе професси бы назывались по-разному. В начале XX века перед архитекторами стояли теже вопросы обеспечения гибкости и лучшего пользовательского опыта. Об этом можно прочитать у Ле Карбюзье в "Дом - машина для жилья". Архитекторы уже тогда понимали, что вот эти фасады, стены - это временное - сегодня ДК, а завтра пятёрочка,
Отчасти я с вами соглашусь. Лично я ещё не встречал тех, у кого был бы неискажённый scrum. Если вы по должности аналитик, а по роли доменный эксперт и владелец продукта, но не менеджер, т.е. вы не форсите побольше задач в спринт, не пытаетесь команду заставить спинт закончить на выходных, то у вас интересный случай) завидую вашим коллегам в таком случае! По рассказам у всех всё правильно, но чаще всего желание получить квартальные/годовые бонусы делает аналитиков немного манагерами)
Я могу сделать всё! Если проект мне нравится, берусь за все роли, чтобы всё взлетело.
А вы рассказываете как должен работать программист, но можете ли взять его работу на себя? Или вам выгодно такое представление, что программист должен свою работу "быстро делать" и "не отвлекаясь"? Услышать бы мнение ваших коллег))
Дополню о своём опыте, потому что намёков сверху было много.
У меня был опыт работы в организации по разработке мед.систем. Я аналитиков не видел, не слышал о них! Тогда мне эта работа не нравилась, но я точно знаю, что продукт был великолепен, конкурентноспособен.
А потому была работа где на 2 прогера 1 аналитик, и менеджмент говорил что ещё нужно. Мол не продукт нужно делать, а понять что делать. Мешками вертеть энто не аналитику делать! Продукт годы топчется на месте, и ещё будет. Потому что чтобы там не придумали аналитики, всё поменяется в силу внешних факторов - конкуренции, где то явно, а где-то опосредовано. Задача стоит так, что нужно не сделать что-то для бизнеса, а как сделать то, что не будет выкинуто в корзину после изменений.
А помимо своего опыта, я ещё и с коллегами общаюсь, на митапы/конфы хожу, книги читаю, ведь нет ничего хуже, чем судить по себе и для себя, а не критически ;)
реализуй сервис по CQRS + EventSourcing c такими-то требованиями
Если наступить себе на горло (потому что будет лукавство сказать что я просто разработчик), то я вам могу ответить что
Вы крадёте инженерную составляющую у разрабов, говоря как делать. Большинство разрабов с высшим образованием. Уже давно нет профессии кодера из бурсы и т.п. Это их работа и компетенции выбирать будут они делать CQRS или нет.
Вы так рассуждаете, потому что хотите на галере занять место не на вёслах, а указвая как грести. Я может открою тайну, но везде всё одинаковое! Мы повторяем одну и туже работу для разных собственников, чтобы они имели конкурентное приемущество. Но все мы живём в одном одинаковом мире, с одинаковыми технологиями, с похожими ограничениями. Ничего уникального, как правило, аналитик не изыщит.
Есть блестящая книга "Фабрики разработки программ". Там есть ужасающая мысль - авторы замечают, что ещё с 80х индустрия проходит стадию ремесленичества и отчаяно нуждается в "индустриализации". Т.е. нужно не плодить людей "нужных", а использовать CI/CD, DDD, микросервисы, Agile и прочее.
Не мало таких людей, которые как и я не испытывают церебрального самоудовлетворения (как говорят физики) от кодинга. Не мало людей кому интересна предметка и её автоматизация/улучшение/автоматизация. Для нас не зазорно сделать всю работу самому, ещё и других научить/документацию оставить.
Не подумайте что я считаю только аналитиков бесполезными. Мой опыт работы и общения говорит о том что мы все бесполезны по большому счёту, т.к. не делаем чаще всего ничего (!) полезного, кроме как делаем кого-то более конкурентно способным....Правильнее будет даже сказать, что аналитики не бесполезны, в аспекте антагонизма работников/собственников, аналитик будет относится к прослойке надсмотрщиков, а поэтому просто не товарищи, когда вторгаются на чужую территорию без просьбы о помощи.
Статья круто началась, жизненно) Закончилась не про войну - про потасовки школоты на перемене)
Я бы докопался до того, что это описание взаимодействия команды ремесленников, которые стучат своими особенными молоточками, чтобы получить конечную заготовку (как булавка у Смита). У команды инженеров вышедший на индустриальный уровень "воинов" не бывает - в худшем случае банка пауков))
Выберите книгу, и с командой поэтапно пробуйте что-либо: спецификации, агрегаты, CQS, иммутабельные типы и т.д. Ошибкой будет пытаться сделать всё сразу, особенно в одиночку.
В идеале наверное да (да и видно что я описался). Базово, согласен. На практике, далеко не любая инфраструктура позволяет получить SLA 99%, не любые требования могут быть реализованы так, как кто-то хочет, далеко не любую архитектуру можно реализовывать по "политическим" решениям. НФТ напрямую не определяют архитектуру, а являются вводными для принятия архитектурно-важных решений. Надеюсь, что все мы разделяем архитектуру и дизайн системы, в том смысле, что первое - это решения трудоёмкие к изменению, а второе - это все детали решения.
На мой взгляд, смысл CN - в том что если всё реализовано правильно, надёжность дело наживное до определённого момента. Я упомянул про облако, про его ИТ-услуги, про зоны доступности - на мой взгляд, это говорит о заданном вопросе до определённой степени. Хорошая вводная на эту тему в книге указанной в источнике: Облачные архитектуры: разработка устойчивых и экономичных облачных приложений | Лащевски Том, Арора Камаль, Фарр Эрик, Зонуз Пийум | 978-5-4461-1588-4
Метрики реальных проектов уже мне не показать. Да и нет в этом никакой необходимости - все крупные организации делают это одинаково - стенды нагрузочного тестирования, SLA, расследование инцидентов и т.п. Я бы сказал, что надёжность - это как раз НФТ, а не архитектура. Это требование куда больше зависит от процесса и вашей инфраструктуры. Описанное выше - это про T2M, perfomance, slalability в первую очередь.
Один из примеров описывал продукт в котором пользователи росли кратно. Закрученная пружина маркетинга далеко не сразу, но очень скачкообразно привела миллионы новых клиентов. Насколько слышал от коллег, большинство строят свою надёжность от конкретных цифр, после чего по мере роста аудитории, доступность падает, требуется пересмотр решения. Наш ответ на подобное плавающее НФТ заключался в работе над типовым микросервисом и связке его с облаком, ит-услугами, с целью формирования сценариев масштабирования.
С одной стороны, я подумаю как осветить в будущих статьях тему доступности, развивающих описанное выше. С другой стороны, мне казалось что слова CloudNative и облако говорят сами за себя - SLA, OPEX/CAPEX обычно подразумеваются (возможно это мои домыслы).
Тем самым, простите, но косвенно отсылаю вас к другим материалам на тему надёжности, которые фокусируются на методологии.
В РФ другая практика - TOGAF, карты бизнес возможностей, Корп.Модель данных; иными словами "коты и мыши". На мой взгляд, статья не раскрывает этой подоплёки, а она и содержит в себе суть того зачем нужна роль архитектора и какие формы это может принимать в разных обстоятельствах. Например, если взять банки или телекомы - это огромные департаменты, которые юзают свои фреймворки, и очень часто на практике не стремятся быть ближе к бизнесу, а становятся частью внутреннего сервиса (вопросы к пуговицам есть?). Этим самовоспроизводящимся системам не нужны ни гибкие подходы, ни DDD)) Иными словами, вряд ли есть коллективы больше 200 человек, всеобъемлюще применяющие такие подходы.
Про DDD и архитекторов много референсов, но в крупных компаниях его убивают архитекторы, а небольших нет системной работы над архитектурой.
Напротив, я утверждаю, что производство будет выполнено дважды в двух формах; форма цифрового продукта отрицает в иной форме его воспроизведение для пользователя. Т.е. формально процесс производства продукта (товара/услуги) происходит в момент выполнения кода. А вот прообраз этого кода - это другая форма работы.
Позволю себе больше, определю эту статью
как агитацию простых решений, которые не требуют больших затрат.
как пропаганду сегрегации ролей в производственном процессе.
И смею думать, что авторов интересовал в этой теме только хайп. Сама же пропаганда коренится в столкновении интересов менеджера и инженера. В одном месте это формулируется как излишняя сложность технического решения, в другом как низкая квалификация программистов и инженеров, в третьем апеллируют к абсолютам. По факту, менеджер всегда преследует задачу оптимальной утилизации ресурсов. И эта статья сильно подыгрывает подобной позиции.
Вы воспроизвели мой ответ, своими словами.
Ещё раз, повторю свою мысль, в доказательство непротиворечивости: форма ПО соответствует материальным условиям развития. В какой-то момент, от вашего продукта может потребоваться рост, с разделением монолита, чтобы соответствовать каким-то метрикам.
Интересная мысль про баланс. ИМХО, лиды/архитекторы/owner'ы именно для соблюдения баланса и нужны, именно в движении противоречивых интересов рождаются, выраствют, умирают все продукты)
Уважаемый собеседник, боюсь вы не правильно поняли мою аналогию. Она не в делимости на части, а в сложности применяемого решения. Внешне для пользователя и то и другое будет схоже. Но для производства смартфонов нужна очень сложная производственная база, цепочки поставок, много версий нужно выпустить. Это уже не говоря о инфраструктуре телекомов.
За такими заявлениями явно есть свои интересы!!!)
Отрицать МСА - это как не пользоваться смартфоном, а только городским телефоном проводным.
Любые сложные системы/подходы/продукты появляются не на ровном месте, не от гения творца, а в ходе длительного развития.
Смысл MSA в том что описанные сложности решаются системно, для всего ландшафта сразу, что даёт "эффект масштаба", позволяет применять эту архитектуру. При этом, конечно, имею место предпосылки к развитию архитектуры на ландшафте.
Выбор архитектуры программного обеспечения, как формы его развития, тесно связан с реализуемой функциональностью и окружающими обстоятельствами. По мере количественного роста, с одной стороны, реализованных фичей, и, с другой стороны, количества заинтересованных сторон, в движении этих внутренних и внешних факторов, форма программного обеспечения склонна изменяться, выражаясь в новой архитектуре решения.
Задача гибкой архитектуры при этом: предвосхитить возможные изменения, производя наиболее адаптируемый к изменениям продукт, приносить заинтересованным сторонам продукт с наиболее высокими потребительскими качествами.
Воспроизведу подобный материализм развития:
Монолитное приложение - это продукт, состоящий из нескольких слоёв или уровней, которые можно выделить логически, иногда физически:
Интерфейс;
Логика приложения;
Слой доступа к данным;
База данных.
Многие продукты и процессы начинаются именно с такой формы. По мере усложнения логики, описания всё большего количества процессов, т.е. при изменении содержания, форма также изменяется.
2. Так или иначе, по мере роста и развития приложения, возникают проблемамы монолитных архитектур:
сложность системы постоянно растет;
поддерживать ее все сложнее и сложнее;
разобраться в ней трудно — особенно если система переходила из поколения в поколение, логика - забывалась, люди уходили и приходили, а комментариев и тестов нет);
много ошибок;
мало тестов — монолит не разобрать и не протестировать, поэтому обычно есть только UI-тесты, поддержка которых обычно занимает много времени;
дорого вносить изменения;
застревание на технологиях
Однако, если приложение приносило пользу стейкхолдерам и развивалось, со временем количество пользователей/операций в системе может значительно вырасти. Появиться необходимость масштабировать систему.
3. Чтобы масштабировать систему, снизить время выхода функциональности, повысить отказоустойчивость и доступность, приходят к микросервисам и облакам.
Т.о. есть предпосылки к появлению микросервисной архитектуры: качественный рост количества фич, правок в них, потребителей.
Профсоюз как низовое движение, отстаивающее интересы коллективов - высшая форма демократии, сознательности рабочих. Вы должны способствовать развитию открытого ПО, поднимать вопрос об отмене собственности на ПО, обговаривать условия труда, но профсоюз ведущий диалог с властью про свой свечной заводик - жёлтый профсоюз.
По поводу экосистемы. Наличие/отсутствие таковой прямо коррелирует с местом страны в мир-системе капиталистической экономики. В условиях тотальной глобализации, крупные компании найдут обходные пути получения железа и софта. А если же экосистема будет реализовываться, то, с одной стороны, спонсировать это будет другой пролетарий, на которого ляжет инфляционная и налоговая нагрузка; с другой стороны, правительство может разыграть в любой момент компрадорскую карту, отказавшись от экосистемы, как уже бывало ни раз за 30 лет.
Вам бы не Мишустиным писать, а писать о том что совсем скоро ждёт всех работников IT, раскрывать методологию органайзинга, агитировать за отстаивание своих рабочих прав.
о CJM
Если или когда найду кокретный анализ для конкретных объектов (такое было, но не всё легко отыскать), обязательно подкреплю к этому ответу.
Я не пытаюсь свою точку зрения навязать, скорее преуменьшить IT как нечто особенное. Правильно смотреть и на здания и на ПО как основной капитал бизнеса (производства). Если смотреть с этой стороны, то разница совсем уж не велика, т.к. и то и другое используется как технические возможности для обеспечения бизнес-процессов.
Вы здессь сразу сузили определение до рамок строительного проекта - корректно ли это? А кто делал проект Москвы-Сити, например? Сейчас чаще всего так и есть, но было время архитекторы проектировали районы и целые города. Сейчас архитектор - дизайнер потому, что строительство исходит не из рациональности, а из профита.
Связь явно есть, иначе професси бы назывались по-разному. В начале XX века перед архитекторами стояли теже вопросы обеспечения гибкости и лучшего пользовательского опыта. Об этом можно прочитать у Ле Карбюзье в "Дом - машина для жилья". Архитекторы уже тогда понимали, что вот эти фасады, стены - это временное - сегодня ДК, а завтра пятёрочка,
Отчасти я с вами соглашусь. Лично я ещё не встречал тех, у кого был бы неискажённый scrum. Если вы по должности аналитик, а по роли доменный эксперт и владелец продукта, но не менеджер, т.е. вы не форсите побольше задач в спринт, не пытаетесь команду заставить спинт закончить на выходных, то у вас интересный случай) завидую вашим коллегам в таком случае!
По рассказам у всех всё правильно, но чаще всего желание получить квартальные/годовые бонусы делает аналитиков немного манагерами)
Я могу сделать всё! Если проект мне нравится, берусь за все роли, чтобы всё взлетело.
А вы рассказываете как должен работать программист, но можете ли взять его работу на себя? Или вам выгодно такое представление, что программист должен свою работу "быстро делать" и "не отвлекаясь"? Услышать бы мнение ваших коллег))
Дополню о своём опыте, потому что намёков сверху было много.
У меня был опыт работы в организации по разработке мед.систем. Я аналитиков не видел, не слышал о них! Тогда мне эта работа не нравилась, но я точно знаю, что продукт был великолепен, конкурентноспособен.
А потому была работа где на 2 прогера 1 аналитик, и менеджмент говорил что ещё нужно. Мол не продукт нужно делать, а понять что делать. Мешками вертеть энто не аналитику делать! Продукт годы топчется на месте, и ещё будет. Потому что чтобы там не придумали аналитики, всё поменяется в силу внешних факторов - конкуренции, где то явно, а где-то опосредовано. Задача стоит так, что нужно не сделать что-то для бизнеса, а как сделать то, что не будет выкинуто в корзину после изменений.
А помимо своего опыта, я ещё и с коллегами общаюсь, на митапы/конфы хожу, книги читаю, ведь нет ничего хуже, чем судить по себе и для себя, а не критически ;)
Если наступить себе на горло (потому что будет лукавство сказать что я просто разработчик), то я вам могу ответить что
Вы крадёте инженерную составляющую у разрабов, говоря как делать. Большинство разрабов с высшим образованием. Уже давно нет профессии кодера из бурсы и т.п. Это их работа и компетенции выбирать будут они делать CQRS или нет.
Вы так рассуждаете, потому что хотите на галере занять место не на вёслах, а указвая как грести. Я может открою тайну, но везде всё одинаковое! Мы повторяем одну и туже работу для разных собственников, чтобы они имели конкурентное приемущество. Но все мы живём в одном одинаковом мире, с одинаковыми технологиями, с похожими ограничениями. Ничего уникального, как правило, аналитик не изыщит.
Есть блестящая книга "Фабрики разработки программ". Там есть ужасающая мысль - авторы замечают, что ещё с 80х индустрия проходит стадию ремесленичества и отчаяно нуждается в "индустриализации". Т.е. нужно не плодить людей "нужных", а использовать CI/CD, DDD, микросервисы, Agile и прочее.
Не мало таких людей, которые как и я не испытывают церебрального самоудовлетворения (как говорят физики) от кодинга. Не мало людей кому интересна предметка и её автоматизация/улучшение/автоматизация. Для нас не зазорно сделать всю работу самому, ещё и других научить/документацию оставить.
Не подумайте что я считаю только аналитиков бесполезными. Мой опыт работы и общения говорит о том что мы все бесполезны по большому счёту, т.к. не делаем чаще всего ничего (!) полезного, кроме как делаем кого-то более конкурентно способным....Правильнее будет даже сказать, что аналитики не бесполезны, в аспекте антагонизма работников/собственников, аналитик будет относится к прослойке надсмотрщиков, а поэтому просто не товарищи, когда вторгаются на чужую территорию без просьбы о помощи.
Статья круто началась, жизненно) Закончилась не про войну - про потасовки школоты на перемене)
Я бы докопался до того, что это описание взаимодействия команды ремесленников, которые стучат своими особенными молоточками, чтобы получить конечную заготовку (как булавка у Смита). У команды инженеров вышедший на индустриальный уровень "воинов" не бывает - в худшем случае банка пауков))
Выберите книгу, и с командой поэтапно пробуйте что-либо: спецификации, агрегаты, CQS, иммутабельные типы и т.д. Ошибкой будет пытаться сделать всё сразу, особенно в одиночку.
Революции сверху? это перед выборами такие лозунги?
Спасибо что правильно меня поняли и за совет. Обязательно почитаю!