Forwarded from ScrumTrek
Ведущий: Сергей Баранов
Модульность без фанатизма: о чем на самом деле книга Balancing Coupling
Встречаемся с Владом Хононовым — архитектором и автором книг «Learning Domain-Driven Design» и «Balancing Coupling in Software Design». Именно об идеях из второй книги мы и поговорим.
Этот вебинар пройдет в формате живой беседы-интервью. Обсудим, как находить баланс между связанностью и модульностью, избегать крайностей в архитектурных решениях и почему связанность не всегда зло — иногда она делает систему прочнее.
Разберем модель Strength–Distance–Volatility и покажем, как применять эти принципы при проектировании устойчивых распределенных систем. 🚀
Приглашаем архитекторов, тимлидов и разработчиков, которые хотят глубже понять тему модульности.
Посмотрим на практические подходы к архитектуре и убедимся, что структурная связанность может стать основой надежности и эволюционного развития системы.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9
Сегодня меня прям убеждали, что ИИ у всех отнимет работу и что сейчас во всем мире сокращают сотни тысяч людей из-за оптимизации через ИИ. Не, в новостях именно так и пишут. И может когда-то так и будет. Но может перед выполнением таких вот KPI имеет смысл приоткрыть занавеску хайпа?) Небольшая подборка косяков ИИ, которые вот прямо сейчас есть. Это не значит, что ИИ - зло, я всеми руками за использование и прогресс, но кажется технология еще не настолько зрелая, чтобы кого-то массово заменить.
————
В рамках исследования в США разрабатывалась нейросеть для оценки риска смертности у больных пневмонией. Целью было определить, каких пациентов можно безопасно лечить амбулаторно, а кого нужно госпитализировать. При обучении модель показала высокую точность на тестовых данных, однако выявилась ошибочная закономерность: алгоритм «решил», что пациенты с бронхиальной астмой имеют пониженный риск смерти при пневмонии.
Ссылка
Ссылка 2
В чем причина? Исторически пациенты с астмой, поступающие с пневмонией, почти всегда направлялись в отделение интенсивной терапии и получали агрессивное лечение и постоянный мониторинг, что резко снижало летальность в их группе. Таким образом, нейронка «увидела» в статистике лишь корреляцию — низкую смертность — и сделала ложный вывод, что сама астма улучшает прогноз, хотя на деле все было наоборот: эти пациенты выживали из‑за своевременной помощи, а не потому, что их состояние было легче.
Нейросети не «понимают» медицину в человеческом смысле. Они ищут статистические закономерности в данных, не различая причинно-следственные связи. Если в истории болезни или клинических записях присутствует системное смещение — например, определённые пациенты чаще получают лечение, или обследования неполны, — алгоритм усваивает эти искажения как «истину». В результате ошибки могут проявляться в неожиданных ситуациях, как с астмой и пневмонией.
Главная сложность использования искусственного интеллекта в медицине — ошибки и смещения (bias) могут возникать где угодно и зачастую заранее непредсказуемы.
Еще примеры:
В США алгоритм прогнозирования потребности в дополнительной медицинской помощи занижал риск у темнокожих пациентов, потому что модель была обучена по затратам на лечение, а не по состоянию здоровья: афроамериканцы исторически получали меньше медицинской помощи, и ИИ принял это за «здоровье».
Компания Workday в США столкнулась с коллективным судебным иском (дело Mobley v. Workday, Inc., 2025 г.) из‑за того, что её ИИ‑система отбора кадров систематически отклоняла пожилых соискателей и людей с инвалидностью. ИИ обучался на исторических данных, где работодатели чаще нанимали более молодых работников, и перенял эту дискриминацию. Суд признал такие алгоритмы потенциальным нарушением Закона о защите от возрастной дискриминации.
В одной из крупных финансовых компаний система ИИ, анализирующая кредитные заявки, отклоняла надежных клиентов как «рискованных». Позже выяснилось, что модель использовала устаревшие данные и не учитывала изменения в поведении клиентов после пандемии.
На крупнейшую медицинскую страховую компанию США UnitedHealthcare подан коллективный иск после расследования Stat News. Алгоритм nH Predict, использовавшийся для принятия решений о выплатах Medicare, систематически завершал реабилитацию пациентов слишком рано и отказывал в продлении покрытия. По данным иска, частота ошибок, приводящих к отказам, достигала 90 %, что лишало людей медицинской помощи и вынуждало оплачивать расходы из личных средств.
Владельцы Apple Card, выпускаемой Goldman Sachs, заметили, что женщины получают значительно меньший кредитный лимит, чем мужчины с аналогичным доходом. Алгоритм скоринга был «слеп» к полу пользователей, но использовал косвенные переменные, коррелирующие с гендером — например, историю покупок и финансовое поведение по совместным счетам. Департамент финансовых услуг Нью‑Йорка начал расследование по факту возможной дискриминации.
В 2025 году в США судью Генри Уингейта обвинили в использовании ИИ‑системы для составления части судебного решения без уведомления сторон процесса.
————
В рамках исследования в США разрабатывалась нейросеть для оценки риска смертности у больных пневмонией. Целью было определить, каких пациентов можно безопасно лечить амбулаторно, а кого нужно госпитализировать. При обучении модель показала высокую точность на тестовых данных, однако выявилась ошибочная закономерность: алгоритм «решил», что пациенты с бронхиальной астмой имеют пониженный риск смерти при пневмонии.
Ссылка
Ссылка 2
В чем причина? Исторически пациенты с астмой, поступающие с пневмонией, почти всегда направлялись в отделение интенсивной терапии и получали агрессивное лечение и постоянный мониторинг, что резко снижало летальность в их группе. Таким образом, нейронка «увидела» в статистике лишь корреляцию — низкую смертность — и сделала ложный вывод, что сама астма улучшает прогноз, хотя на деле все было наоборот: эти пациенты выживали из‑за своевременной помощи, а не потому, что их состояние было легче.
Нейросети не «понимают» медицину в человеческом смысле. Они ищут статистические закономерности в данных, не различая причинно-следственные связи. Если в истории болезни или клинических записях присутствует системное смещение — например, определённые пациенты чаще получают лечение, или обследования неполны, — алгоритм усваивает эти искажения как «истину». В результате ошибки могут проявляться в неожиданных ситуациях, как с астмой и пневмонией.
Главная сложность использования искусственного интеллекта в медицине — ошибки и смещения (bias) могут возникать где угодно и зачастую заранее непредсказуемы.
Еще примеры:
В США алгоритм прогнозирования потребности в дополнительной медицинской помощи занижал риск у темнокожих пациентов, потому что модель была обучена по затратам на лечение, а не по состоянию здоровья: афроамериканцы исторически получали меньше медицинской помощи, и ИИ принял это за «здоровье».
Компания Workday в США столкнулась с коллективным судебным иском (дело Mobley v. Workday, Inc., 2025 г.) из‑за того, что её ИИ‑система отбора кадров систематически отклоняла пожилых соискателей и людей с инвалидностью. ИИ обучался на исторических данных, где работодатели чаще нанимали более молодых работников, и перенял эту дискриминацию. Суд признал такие алгоритмы потенциальным нарушением Закона о защите от возрастной дискриминации.
В одной из крупных финансовых компаний система ИИ, анализирующая кредитные заявки, отклоняла надежных клиентов как «рискованных». Позже выяснилось, что модель использовала устаревшие данные и не учитывала изменения в поведении клиентов после пандемии.
На крупнейшую медицинскую страховую компанию США UnitedHealthcare подан коллективный иск после расследования Stat News. Алгоритм nH Predict, использовавшийся для принятия решений о выплатах Medicare, систематически завершал реабилитацию пациентов слишком рано и отказывал в продлении покрытия. По данным иска, частота ошибок, приводящих к отказам, достигала 90 %, что лишало людей медицинской помощи и вынуждало оплачивать расходы из личных средств.
Владельцы Apple Card, выпускаемой Goldman Sachs, заметили, что женщины получают значительно меньший кредитный лимит, чем мужчины с аналогичным доходом. Алгоритм скоринга был «слеп» к полу пользователей, но использовал косвенные переменные, коррелирующие с гендером — например, историю покупок и финансовое поведение по совместным счетам. Департамент финансовых услуг Нью‑Йорка начал расследование по факту возможной дискриминации.
В 2025 году в США судью Генри Уингейта обвинили в использовании ИИ‑системы для составления части судебного решения без уведомления сторон процесса.
❤7👍3🤣1
В тексте постановления оказались ошибки и ложные ссылки на судебные прецеденты, созданные нейросетью.
В нескольких странах произошла волна дел, когда юристы представляли в судах вымышленные решения и цитаты, сгенерированные ChatGPT и Google Bard. В США после таких случаев были введены правила, обязывающие юристов прикладывать сертификат достоверности к каждому документу, где использовался ИИ. Подобные инциденты зафиксированы и в Канаде, где из десяти судебных ссылок, представленных в иске, девять оказались придуманы нейросетью.
Технологии автоматического распознавания лиц, применяемые полицией и судами, также привели к громким нарушениям. В США Роберт Уильямс был ошибочно арестован в Детройте после того, как алгоритм совмещённого поиска воспринял его лицо как совпадающее с фото преступника. Он провёл сутки под арестом, хотя не имел отношения к делу. В России в 2023 году гидролог Александр Цветков провёл 10 месяцев в СИЗО по обвинению в убийствах из‑за совпадения с фотороботом, созданным ИИ‑системой
В Китае и США тестируются системы алгоритмических «рекомендаций наказания». Они анализируют сотни тысяч приговоров и предлагают судьям стандартный диапазон санкций. Однако исследования показывают, что такие модели склонны усиливать уже существующие диспропорции — например, назначать более строгие наказания молодым мужчинам или выходцам из меньшинств, поскольку обучены на исторических данных тех же судов.
И самое вкусное:
По данным Uplevel (2025 г.), количество багов в проектном коде с участием ИИ выросло на 41 % по сравнению с ручной разработкой. Нейросеть может оптимизировать структуру, но не «понимает» бизнес‑логику, что особенно критично в финтех‑ и медтех‑проектах.
Согласно исследованиям MIT и RAND (2025 г.), около 95 % генеративных ИИ‑пилотов в IT‑отрасли не достигают стадии коммерческого внедрения. Причины — нестыковка между задачами бизнеса и техническими возможностями, завышенные ожидания и плохое качество данных.
Согласно исследованию, опубликованному в январе 2025 г. , от 22 % до 48 % примеров кода, созданных популярными моделями (ChatGPT, Copilot, Gemini, JetBrains AI Assistant), содержали реальные уязвимости — от SQL‑инъекций до ошибок обработки строк. Особенно часто ИИ придумывал пакеты и импортировал несуществующие зависимости, создавая атаки через supply‑chain, если эти пакеты подменялись злоумышленниками.
Анализ компании Anaconda выявил, что 60 % ИТ‑директоров оценивают влияние ошибок ИИ‑кодогенерации как «очень серьёзное». В одном случае генеративная модель Terraform от внутреннего ИИ‑бота предложила настройки, удаляющие часть инфраструктуры AWS без резервирования. В результате временно перестали работать клиентские API‑сервисы, а ущерб составил около 200 000 долларов.
Исследование AI‑Generated Code Riss (2024–2025) подтвердило, что мелкие синтаксические дефекты и неверные конфигурации ИИ‑кода часто вызывают каскадные инциденты безопасности. Примеры включают ошибочную обработку ошибок сетевых запросов, что приводило к падению Docker‑контейнеров, и внедрение шаблонов уязвимых API в коммерческие приложения через LLM‑рекомендации.
В 2025 году предприниматель создал веб‑приложение с помощью ChatGPT. Оно работало исправно до тех пор, пока пользователи не стали вводить некорректные данные. Модель не предусмотрела валидацию ввода — в результате возникла ошибка деления на ноль, а позже обнаружили SQL‑инъекцию, позволившую хакеру получить доступ к базе клиентов. Через два месяца компания потеряла базу данных и 80 % пользователей.
Компания Veracode протестировала более 100 моделей (ChatGPT, Gemini, Anthropic Claude и др.) и выявила, что 45 % примеров кода содержали критические уязвимости из OWASP Top‑10. Наиболее часто встречались XSS‑атаки и SQL‑инъекции. Самый высокий уровень небезопасности оказался у Java‑кода — 72 % программ не проходили проверку на безопасность.
В августе 2025 года разработчики отметили, что новая версия ChatGPT‑5 систематически создавала ошибки в HTML‑формах и API‑запросах — в 45 % случаев параметры не совпадали по именам между клиентом и сервером.
В нескольких странах произошла волна дел, когда юристы представляли в судах вымышленные решения и цитаты, сгенерированные ChatGPT и Google Bard. В США после таких случаев были введены правила, обязывающие юристов прикладывать сертификат достоверности к каждому документу, где использовался ИИ. Подобные инциденты зафиксированы и в Канаде, где из десяти судебных ссылок, представленных в иске, девять оказались придуманы нейросетью.
Технологии автоматического распознавания лиц, применяемые полицией и судами, также привели к громким нарушениям. В США Роберт Уильямс был ошибочно арестован в Детройте после того, как алгоритм совмещённого поиска воспринял его лицо как совпадающее с фото преступника. Он провёл сутки под арестом, хотя не имел отношения к делу. В России в 2023 году гидролог Александр Цветков провёл 10 месяцев в СИЗО по обвинению в убийствах из‑за совпадения с фотороботом, созданным ИИ‑системой
В Китае и США тестируются системы алгоритмических «рекомендаций наказания». Они анализируют сотни тысяч приговоров и предлагают судьям стандартный диапазон санкций. Однако исследования показывают, что такие модели склонны усиливать уже существующие диспропорции — например, назначать более строгие наказания молодым мужчинам или выходцам из меньшинств, поскольку обучены на исторических данных тех же судов.
И самое вкусное:
По данным Uplevel (2025 г.), количество багов в проектном коде с участием ИИ выросло на 41 % по сравнению с ручной разработкой. Нейросеть может оптимизировать структуру, но не «понимает» бизнес‑логику, что особенно критично в финтех‑ и медтех‑проектах.
Согласно исследованиям MIT и RAND (2025 г.), около 95 % генеративных ИИ‑пилотов в IT‑отрасли не достигают стадии коммерческого внедрения. Причины — нестыковка между задачами бизнеса и техническими возможностями, завышенные ожидания и плохое качество данных.
Согласно исследованию, опубликованному в январе 2025 г. , от 22 % до 48 % примеров кода, созданных популярными моделями (ChatGPT, Copilot, Gemini, JetBrains AI Assistant), содержали реальные уязвимости — от SQL‑инъекций до ошибок обработки строк. Особенно часто ИИ придумывал пакеты и импортировал несуществующие зависимости, создавая атаки через supply‑chain, если эти пакеты подменялись злоумышленниками.
Анализ компании Anaconda выявил, что 60 % ИТ‑директоров оценивают влияние ошибок ИИ‑кодогенерации как «очень серьёзное». В одном случае генеративная модель Terraform от внутреннего ИИ‑бота предложила настройки, удаляющие часть инфраструктуры AWS без резервирования. В результате временно перестали работать клиентские API‑сервисы, а ущерб составил около 200 000 долларов.
Исследование AI‑Generated Code Riss (2024–2025) подтвердило, что мелкие синтаксические дефекты и неверные конфигурации ИИ‑кода часто вызывают каскадные инциденты безопасности. Примеры включают ошибочную обработку ошибок сетевых запросов, что приводило к падению Docker‑контейнеров, и внедрение шаблонов уязвимых API в коммерческие приложения через LLM‑рекомендации.
В 2025 году предприниматель создал веб‑приложение с помощью ChatGPT. Оно работало исправно до тех пор, пока пользователи не стали вводить некорректные данные. Модель не предусмотрела валидацию ввода — в результате возникла ошибка деления на ноль, а позже обнаружили SQL‑инъекцию, позволившую хакеру получить доступ к базе клиентов. Через два месяца компания потеряла базу данных и 80 % пользователей.
Компания Veracode протестировала более 100 моделей (ChatGPT, Gemini, Anthropic Claude и др.) и выявила, что 45 % примеров кода содержали критические уязвимости из OWASP Top‑10. Наиболее часто встречались XSS‑атаки и SQL‑инъекции. Самый высокий уровень небезопасности оказался у Java‑кода — 72 % программ не проходили проверку на безопасность.
В августе 2025 года разработчики отметили, что новая версия ChatGPT‑5 систематически создавала ошибки в HTML‑формах и API‑запросах — в 45 % случаев параметры не совпадали по именам между клиентом и сервером.
www.rand.org
Why AI Projects Fail and How They Can Succeed
By some estimates, more than 80 percent of AI projects fail. That's twice the rate of failure of information technology projects that do not involve AI. Interviews with data scientists and engineers in industry and academia highlight five leading root causes…
❤4🔥1
Это вызывало неправильную передачу данных и падения фронта. Ошибка получила широкое обсуждение как пример «массового переобучения без понимания контекста».
Аналитика DevOps‑платформы DORA показала, что массовое внедрение GitHub Copilot вызвало падение стабильности релизов на 7,2 %: ИИ часто генерировал «рабочий» код без оптимизации. Пример — автоматическая реализация быстрой сортировки, предложенная Copilot вместо стандартной функции
Исследование Security Degradation in Iterative AI Code Generation (2025 г.) зафиксировало парадокс: при каждой новой итерации «улучшения кода» через LLM количество уязвимостей возрастало на 37 %. Алгоритм ChatGPT при внесении косметических правок добавлял новые риски, такие как несанкционированное использование пользовательских данных или утечки через логирование ошибок. Эксперимент показал, что «оптимизация» через самообучение без участия человека ухудшает безопасность, а не повышает.
Аналитика DevOps‑платформы DORA показала, что массовое внедрение GitHub Copilot вызвало падение стабильности релизов на 7,2 %: ИИ часто генерировал «рабочий» код без оптимизации. Пример — автоматическая реализация быстрой сортировки, предложенная Copilot вместо стандартной функции
.sort(), вызывала зависания при обработке больших массивов. Для исправления брешей аналогичные фрагменты приходилось переписывать вручную.Исследование Security Degradation in Iterative AI Code Generation (2025 г.) зафиксировало парадокс: при каждой новой итерации «улучшения кода» через LLM количество уязвимостей возрастало на 37 %. Алгоритм ChatGPT при внесении косметических правок добавлял новые риски, такие как несанкционированное использование пользовательских данных или утечки через логирование ошибок. Эксперимент показал, что «оптимизация» через самообучение без участия человека ухудшает безопасность, а не повышает.
🔥8❤1
А на десерт на тему архитектуры.
Построение фасадов… стоп, не оттуда. Или оттуда?)
В общем, мне никак не удается ни дипсик, ни чатгпт, ни перплексити заставить в архитектурных вопросах, я про нашу архитектуру, не использовать материалы из другой архитектуры, которая про строительство.
В чем проблема?
А в том, что большая часть терминов в IT архитектуре хоть и имеет свое значенине, но сами слова заимствованы…. вроде отвечает про IT архитеткру и по ходу примешивает BIM, CAD…
Спрашиваешь его про производительность и можно получить (цитата):
«ИИ анализирует энергопотребление, освещение, вентиляцию и другие параметры зданий для оптимизации их производительности.»
Или вот еще мой пример:
«Автоматизация рутинных задач позволяет архитекторам сосредоточиться на творческих аспектах проектирования. ИИ может обрабатывать сложные расчеты и генерировать множество вариантов дизайна за секунды, что ранее требовало месяцев работы.»
Похоже на правду?
Конечно, только оно мне еще ссылку не источник приложило:
https://www.ube.ac.uk/whats-happening/articles/generative-design/
К слову, даже читая источник не сразу догадаешься, что речь не про IT-архитектуру.
Так что очень надеюсь, что или хайп спадет или пелена с глаз, иначе нас не ИИ убьет, как некоторые прогнозируют, а мы сами себя просто из-за того, что слишком доверились новому.
А ведь когда-то все болезни лечили кровопусканием… тоже своего рода была «серебряная пуля».
Построение фасадов… стоп, не оттуда. Или оттуда?)
В общем, мне никак не удается ни дипсик, ни чатгпт, ни перплексити заставить в архитектурных вопросах, я про нашу архитектуру, не использовать материалы из другой архитектуры, которая про строительство.
В чем проблема?
А в том, что большая часть терминов в IT архитектуре хоть и имеет свое значенине, но сами слова заимствованы…. вроде отвечает про IT архитеткру и по ходу примешивает BIM, CAD…
Спрашиваешь его про производительность и можно получить (цитата):
«ИИ анализирует энергопотребление, освещение, вентиляцию и другие параметры зданий для оптимизации их производительности.»
Или вот еще мой пример:
«Автоматизация рутинных задач позволяет архитекторам сосредоточиться на творческих аспектах проектирования. ИИ может обрабатывать сложные расчеты и генерировать множество вариантов дизайна за секунды, что ранее требовало месяцев работы.»
Похоже на правду?
Конечно, только оно мне еще ссылку не источник приложило:
https://www.ube.ac.uk/whats-happening/articles/generative-design/
К слову, даже читая источник не сразу догадаешься, что речь не про IT-архитектуру.
Так что очень надеюсь, что или хайп спадет или пелена с глаз, иначе нас не ИИ убьет, как некоторые прогнозируют, а мы сами себя просто из-за того, что слишком доверились новому.
А ведь когда-то все болезни лечили кровопусканием… тоже своего рода была «серебряная пуля».
University of the Built Environment
The architect’s guide to generative design
Generative design is transforming the way architects and built environment professionals approach the design phase of construction projects.
👍6🤣4❤1👌1
И как вы могли заметить, все примеры тоже сгенерированы ИИ, Perplexity. Они все уверенно складные и не вызывают ни капли сомнений :) Но кто знает сколько там правды.
Нейронки отлично разбираются в том, в чем я не разбираюсь, но ничего не понимают в том, в чем я хорошо понимаю…
Вот прямо сейчас спросил перплексити. И ведь кто-то пойдет задавать вопросы, развивая этот этот ответ, вплоть до реализации. А хорош ли этот ответ?
Какой архитектурные стиль подойдет для реализации небольшого локального интернет-магазина?
Ответ:
Для небольшого локального интернет-магазина оптимальным архитектурным стилем является микросервисная архитектура, если проект ориентирован на устойчивость, гибкость и долгосрочное развитие. Такой подход позволяет сразу выстроить современную, масштабируемую и надёжную основу без ограничений, свойственных монолитным решениям.
Почему микросервисы подходят локальному магазину
1. Гибкость и независимость сервисов. Каждый компонент — каталог, корзина, заказы, платежи — работает отдельно. Это позволяет добавлять новые функции без переписывания всего сайта и гарантирует устойчивость при сбоях.
2. Простое масштабирование. Даже если магазин локальный, отдельные сервисы (например, каталог или оплата) можно масштабировать при росте покупателей или расширении ассортимента.
3. Лёгкость поддержки и обновлений. Маленькая команда может обновлять конкретный модуль без остановки магазина. Это особенно удобно, если магазин развивается постепенно.
4. Техническая независимость. При необходимости можно разворачивать микросервисы на недорогих локальных серверах или облачных решениях — Yandex Cloud, Timeweb Cloud и пр..
5.Будущее‑ориентированность. Если магазин вырастет, микросервисная система безболезненно адаптируется к региональному или даже национальному уровню бизнеса.
Нейронки отлично разбираются в том, в чем я не разбираюсь, но ничего не понимают в том, в чем я хорошо понимаю…
Вот прямо сейчас спросил перплексити. И ведь кто-то пойдет задавать вопросы, развивая этот этот ответ, вплоть до реализации. А хорош ли этот ответ?
Какой архитектурные стиль подойдет для реализации небольшого локального интернет-магазина?
Ответ:
Для небольшого локального интернет-магазина оптимальным архитектурным стилем является микросервисная архитектура, если проект ориентирован на устойчивость, гибкость и долгосрочное развитие. Такой подход позволяет сразу выстроить современную, масштабируемую и надёжную основу без ограничений, свойственных монолитным решениям.
Почему микросервисы подходят локальному магазину
1. Гибкость и независимость сервисов. Каждый компонент — каталог, корзина, заказы, платежи — работает отдельно. Это позволяет добавлять новые функции без переписывания всего сайта и гарантирует устойчивость при сбоях.
2. Простое масштабирование. Даже если магазин локальный, отдельные сервисы (например, каталог или оплата) можно масштабировать при росте покупателей или расширении ассортимента.
3. Лёгкость поддержки и обновлений. Маленькая команда может обновлять конкретный модуль без остановки магазина. Это особенно удобно, если магазин развивается постепенно.
4. Техническая независимость. При необходимости можно разворачивать микросервисы на недорогих локальных серверах или облачных решениях — Yandex Cloud, Timeweb Cloud и пр..
5.Будущее‑ориентированность. Если магазин вырастет, микросервисная система безболезненно адаптируется к региональному или даже национальному уровню бизнеса.
😁22👍4🔥3🤔1
Готовлюсь к своему выступлению на ArchDays, периодически попадаются прям сокровища, которые поиском найти бывает очень сложно, вот пример
https://t.me/ru_arc_files/18
https://t.me/ru_arc_files/18
👍6🤣2🤔1
Forwarded from Блог Сергея Баранова (Сергей Баранов)
А первый пост будет как раз про микросервисы 😂
В общем, кейс был в том, что компания (в компании не было на тот момент архитектора) приняла решение заменить систему, которую разрабатывала много лет на новое решение. Объективных причин много, но суть не в этом, а в том, что выбрали архитектурный стиль какой? Правильно, микросервисный.
И это история, которая подходит под не менее 50% случаев всех переходов.
Допустим, пристально посмотрев на бизнес-модель и архитектурно-значимые требования мы э обнаружили, что ни одной предпосылки к микросервисам нет. И нагрузка небольшая и предсказуемая, и модульность такая сильная не очень-то нужна.
И посмотрим теперь на микросервисы в сравнении с монолитом с позиции экономики:
- это распределенная система, а значит более высокие требования к разработчикам, а значит рост ФОТ
- по той же причине, да еще и вследствие более сложной архитектуры - это плюс 1, 2, 3, n devops-инженеров
- это более сложные процессы тестирования, управления зависимостями, интеграциями, а это дополнительное время тех дорогих людей, о которых я написал выше, а работу работать надо, значит этих дорогих людей надо немного больше (если все только начинается, то на микросервисы нужно в среднем на 10-30 разработчиков больше, чем на монолит)
- а если это в облаке - вот вам счет в N раз больше за аренду мощностей и инфраструктурных компонентов в облаке
И это очень сильно разгоняет общую стоимость владения, а мы помним, что по условию задачи, никакой бизнес- или архитектурной потребности не было и в итоге мы получаем значительное удорожание решения без какой-либо безнес ценности (то есть фактически просто так стали больше тратить), а самое печальное, что в условиях текущих цен и зарплат синьор-специалистов это может съесть всю прибыль компании… и самое печальное, - если на этом фоне начать кадровую оптимизацию, то есть уволить синьоров, попытаться нанять людей с меньшим опытом, то, учитывая специфику микросервисов, - распределенная система, сложна инфраструктура,не самые простые процессы разработки и тестирования, достаточно замысловатый мониторинг, - это вполне может стать началом конца.
И все это, прошу обратить внимание, про экономику :)
В общем, кейс был в том, что компания (в компании не было на тот момент архитектора) приняла решение заменить систему, которую разрабатывала много лет на новое решение. Объективных причин много, но суть не в этом, а в том, что выбрали архитектурный стиль какой? Правильно, микросервисный.
И это история, которая подходит под не менее 50% случаев всех переходов.
Допустим, пристально посмотрев на бизнес-модель и архитектурно-значимые требования мы э обнаружили, что ни одной предпосылки к микросервисам нет. И нагрузка небольшая и предсказуемая, и модульность такая сильная не очень-то нужна.
И посмотрим теперь на микросервисы в сравнении с монолитом с позиции экономики:
- это распределенная система, а значит более высокие требования к разработчикам, а значит рост ФОТ
- по той же причине, да еще и вследствие более сложной архитектуры - это плюс 1, 2, 3, n devops-инженеров
- это более сложные процессы тестирования, управления зависимостями, интеграциями, а это дополнительное время тех дорогих людей, о которых я написал выше, а работу работать надо, значит этих дорогих людей надо немного больше (если все только начинается, то на микросервисы нужно в среднем на 10-30 разработчиков больше, чем на монолит)
- а если это в облаке - вот вам счет в N раз больше за аренду мощностей и инфраструктурных компонентов в облаке
И это очень сильно разгоняет общую стоимость владения, а мы помним, что по условию задачи, никакой бизнес- или архитектурной потребности не было и в итоге мы получаем значительное удорожание решения без какой-либо безнес ценности (то есть фактически просто так стали больше тратить), а самое печальное, что в условиях текущих цен и зарплат синьор-специалистов это может съесть всю прибыль компании… и самое печальное, - если на этом фоне начать кадровую оптимизацию, то есть уволить синьоров, попытаться нанять людей с меньшим опытом, то, учитывая специфику микросервисов, - распределенная система, сложна инфраструктура,не самые простые процессы разработки и тестирования, достаточно замысловатый мониторинг, - это вполне может стать началом конца.
И все это, прошу обратить внимание, про экономику :)
🔥18❤3👍3
Оцените, насколько понятна для вас архитектура текущего проекта, если бы вы только пришли в проект и вам поручили добавить новую фичу или устранить баг.
1 — «невозможно разобраться без долгого онбординга»
5 — «можно начать писать код почти сразу»
1 — «невозможно разобраться без долгого онбординга»
5 — «можно начать писать код почти сразу»
Anonymous Poll
18%
1
20%
2
32%
3
19%
4
11%
5
❤1🤔1
Вы, как архитектор, оцениваете экономические последствия принимаемых архитектурных решений (то есть не после принятия, а как один из параметров принятии)?
Anonymous Poll
47%
Да
13%
Нет
40%
Я не архитектор, посмотреть ответы
Давайте проверим, нужно риски сообщества оценить.
У меня телеграм стал тормозить примерно последнюю неделю (долго подключатся, медленно отправляет и скачивает и так далее).
У меня телеграм стал тормозить примерно последнюю неделю (долго подключатся, медленно отправляет и скачивает и так далее).
Anonymous Poll
30%
Да, я в РФ
3%
Да, я не в РФ
50%
Нет, я в РФ
17%
Нет, я не в РФ
🤔8
Forwarded from Конференция ArchDays
Ведущий: Сергей Баранов.
Гостем был Влад Хононов, архитектор и автор книг «Learning Domain-Driven Design» и «Balancing Coupling in Software Design». Вебинар посвящён идеям из второй книги.
Это была живая беседа: обсуждали, как найти баланс между связанностью и модульностью, почему связанность не всегда плохо, а иногда помогает сделать систему крепче.
Смотрите видео:
Please open Telegram to view this post
VIEW IN TELEGRAM
VK Видео
Модульность без фанатизма: о чем на самом деле книга Balancing Coupling
Официальный канал ArchDays в Telegram: https://t.me/archdays Встречаемся с Владом Хононовым — архитектором и автором книг «Learning Domain-Driven Design» и «Balancing Coupling in Software Design». Именно об идеях из второй книги мы и поговорим. Этот вебинар…
👍6❤3🔥2
☝️ Коллеги, хотелось бы напомнить, что у канала есть группа: @ru_arc_chat , в которой тонны полезной информации. Добавляйтесь.
Telegram
RASA Chat
Группа тг-канала объединения ИТ-архитекторов (@ru_arc)
Правила группы: https://t.me/ru_arc_chat/2036
По бизнес-вопросам (ИП, ООО, ВЭД):
@rasa_business
Практические кейсы:
@archicases
Предложить доклад для митапа: @ru_arc_meetup_bot
Правила группы: https://t.me/ru_arc_chat/2036
По бизнес-вопросам (ИП, ООО, ВЭД):
@rasa_business
Практические кейсы:
@archicases
Предложить доклад для митапа: @ru_arc_meetup_bot
Краткое содержание обсуждений
1. Языки программирования и их история
Lisp и его диалекты (Scheme, Common Lisp) — фундамент для многих современных языков (Ruby, Java).
История сборщиков мусора, роль CLU как предтечи ООП.
Анализ решений Билла Джоя с участием Гая Стила.
Ссылки:
https://github.com/robpike/lisp
https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)
http://www.pmg.lcs.mit.edu/ftp.lcs.mit.edu/pub/pclu/CLU/3.Documents/clu-history.PDF
2. AWS регион us-east-1 сбои и риск SPOF
Обсуждение масштабного сбоя AWS, затрагивающего DynamoDB, Slack и сервисы мониторинга.
Вопросы Single Point of Failure.
Ссылка: https://health.aws.amazon.com/health/status
3. CI/CD инструменты open source и сравнительный анализ
Основные системы: GitLab CI, ArgoCD, Tekton, Jenkins, Concourse, Woodpecker, Drone, Prow, Gitea/Forgejo.
Tekton признан облачным нативным решением CNCF с лучшей архитектурой в сравнении с Jenkins.
GitLab CI тяжеловесен, ArgoCD имеет проблемы с безопасностью и масштабируемостью.
Ссылка:
https://www.redhat.com/en/blog/tekton-vs-jenkins-whats-better-cicd-pipelines-red-hat-openshift
https://docs.prow.k8s.io/docs/overview/
4. Технический долг и архитектура
Технический долг — экспоненциально растущий риск от несоответствия кодовой базы будущим требованиям.
Основные причины: плохой менеджмент, нехватка ресурсов, недостаточная квалификация команды.
Важна правильная классификация долгов и грамотное управление ими для здоровой разработки.
Практические кейсы демонстрируют, что без качественного менеджмента рефакторинг неэффективен.
5. Моделирование бизнес-процессов и трассировка требований
Структурирование базы знаний: бизнес-процессы, требования, сценарии, операции.
Важность автономности процессов и traceability от требований до кода и обратно.
Обсуждение проблем циклических зависимостей и разбиения команд по доменам.
Используются методы DDD, Event Storming, Wardley Mapping.
Ссылки:
https://less.works/ru/less/framework/coordination-and-integration
https://pmc.ncbi.nlm.nih.gov/articles/PMC8918592/
https://www.volere.org/tools/
6. Разработка локального интернет-магазина: архитектура и платформы
Рекомендация для небольшого магазина — монолит или модульный монолит, чтобы избежать оверхеда микросервисов.
Стек: Laravel, Django, Ruby on Rails, Node.js/Express, PostgreSQL/MySQL.
CMS и SaaS платформы как быстрые стартовые решения: Bitrix, InSales, WooCommerce, OpenCart.
Уточняющие факторы: объем каталога, бюджет, команда, способы оплаты и доставки.
7. Когнитивные аспекты и командная коммуникация
Ограничения восприятия у разработчиков, важность разделения знаний по Bounded Context.
Обмен знаниями через tech talks, репозитории знаний, общие области ответственности по Less.
8. Искусственный интеллект: ошибки, риски, влияние на качество кода
Кейсы ошибок ИИ в медицине, HR, судебных решениях, распознавании лиц.
Рост багов в коде, сгенерированном ИИ, падение стабильности релизов с GitHub Copilot.
9. API-first, контрактное тестирование и архитектурные паттерны
Эволюция представления Use Cases, CQRS, хексагональной архитектуры.
Различия событий и команд в DDD и event-driven системах — дискуссии о владении сообщениями, степенях связанности.
Возможности и ограничения API-first подхода.
10. Телеком и безопасность
Введение «периода охлаждения» для SIM-карт в России.
Обсуждение доступности Telegram и альтернативных платформ (Mattermost, Rocket.Chat, VK).
Идеи децентрализованных мессенджеров и мультипротокольных клиентов (Pidgin, Keet).
11. Инфраструктура и DevOps практики
Выгрузка данных из БД в оперативную память для ускорения гео- и маршрутизационных сервисов (taxi).
Использование CDC (Change Data Capture) с PostgreSQL для синхронизации с низкой задержкой.
Обсуждение рисков SPOF (Single Point Of Failure) в Cloudflare, AWS и уроки их отказоустойчивости.
1. Языки программирования и их история
Lisp и его диалекты (Scheme, Common Lisp) — фундамент для многих современных языков (Ruby, Java).
История сборщиков мусора, роль CLU как предтечи ООП.
Анализ решений Билла Джоя с участием Гая Стила.
Ссылки:
https://github.com/robpike/lisp
https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)
http://www.pmg.lcs.mit.edu/ftp.lcs.mit.edu/pub/pclu/CLU/3.Documents/clu-history.PDF
2. AWS регион us-east-1 сбои и риск SPOF
Обсуждение масштабного сбоя AWS, затрагивающего DynamoDB, Slack и сервисы мониторинга.
Вопросы Single Point of Failure.
Ссылка: https://health.aws.amazon.com/health/status
3. CI/CD инструменты open source и сравнительный анализ
Основные системы: GitLab CI, ArgoCD, Tekton, Jenkins, Concourse, Woodpecker, Drone, Prow, Gitea/Forgejo.
Tekton признан облачным нативным решением CNCF с лучшей архитектурой в сравнении с Jenkins.
GitLab CI тяжеловесен, ArgoCD имеет проблемы с безопасностью и масштабируемостью.
Ссылка:
https://www.redhat.com/en/blog/tekton-vs-jenkins-whats-better-cicd-pipelines-red-hat-openshift
https://docs.prow.k8s.io/docs/overview/
4. Технический долг и архитектура
Технический долг — экспоненциально растущий риск от несоответствия кодовой базы будущим требованиям.
Основные причины: плохой менеджмент, нехватка ресурсов, недостаточная квалификация команды.
Важна правильная классификация долгов и грамотное управление ими для здоровой разработки.
Практические кейсы демонстрируют, что без качественного менеджмента рефакторинг неэффективен.
5. Моделирование бизнес-процессов и трассировка требований
Структурирование базы знаний: бизнес-процессы, требования, сценарии, операции.
Важность автономности процессов и traceability от требований до кода и обратно.
Обсуждение проблем циклических зависимостей и разбиения команд по доменам.
Используются методы DDD, Event Storming, Wardley Mapping.
Ссылки:
https://less.works/ru/less/framework/coordination-and-integration
https://pmc.ncbi.nlm.nih.gov/articles/PMC8918592/
https://www.volere.org/tools/
6. Разработка локального интернет-магазина: архитектура и платформы
Рекомендация для небольшого магазина — монолит или модульный монолит, чтобы избежать оверхеда микросервисов.
Стек: Laravel, Django, Ruby on Rails, Node.js/Express, PostgreSQL/MySQL.
CMS и SaaS платформы как быстрые стартовые решения: Bitrix, InSales, WooCommerce, OpenCart.
Уточняющие факторы: объем каталога, бюджет, команда, способы оплаты и доставки.
7. Когнитивные аспекты и командная коммуникация
Ограничения восприятия у разработчиков, важность разделения знаний по Bounded Context.
Обмен знаниями через tech talks, репозитории знаний, общие области ответственности по Less.
8. Искусственный интеллект: ошибки, риски, влияние на качество кода
Кейсы ошибок ИИ в медицине, HR, судебных решениях, распознавании лиц.
Рост багов в коде, сгенерированном ИИ, падение стабильности релизов с GitHub Copilot.
9. API-first, контрактное тестирование и архитектурные паттерны
Эволюция представления Use Cases, CQRS, хексагональной архитектуры.
Различия событий и команд в DDD и event-driven системах — дискуссии о владении сообщениями, степенях связанности.
Возможности и ограничения API-first подхода.
10. Телеком и безопасность
Введение «периода охлаждения» для SIM-карт в России.
Обсуждение доступности Telegram и альтернативных платформ (Mattermost, Rocket.Chat, VK).
Идеи децентрализованных мессенджеров и мультипротокольных клиентов (Pidgin, Keet).
11. Инфраструктура и DevOps практики
Выгрузка данных из БД в оперативную память для ускорения гео- и маршрутизационных сервисов (taxi).
Использование CDC (Change Data Capture) с PostgreSQL для синхронизации с низкой задержкой.
Обсуждение рисков SPOF (Single Point Of Failure) в Cloudflare, AWS и уроки их отказоустойчивости.
GitHub
GitHub - robpike/lisp: Toy Lisp 1.5 interpreter
Toy Lisp 1.5 interpreter. Contribute to robpike/lisp development by creating an account on GitHub.
❤2👍1🤔1
12. Дискуссии по микросервисам и монолитам
Для команд до ~200 человек вполне эффективен модульный монолит.
Микросервисы оправданы лишь для больших распределенных команд с высокой сложностью.
Ключевые полезные ссылки
AWS инциденты: https://health.aws.amazon.com/health/status
Rob Pike о Lisp: https://github.com/robpike/lisp
История CLU — прототип ООП: http://www.pmg.lcs.mit.edu/ftp.lcs.mit.edu/pub/pclu/CLU/3.Documents/clu-history.PDF
RedHat о Tekton vs Jenkins: https://www.redhat.com/en/blog/tekton-vs-jenkins-whats-better-cicd-pipelines-red-hat-openshift
Prow — CI/CD для Kubernetes: https://docs.prow.k8s.io/docs/overview/
Модель управления рисками (CMU): https://www.sei.cmu.edu/documents/5836/Continuous_Risk_Management_Guidebook.pdf
Feature Flags на Go: https://github.com/thomaspoignant/go-feature-flag
Toggly — блог по feature flags: https://toggly.io/
Less Framework (coordination and knowledge sharing): https://less.works/ru/less/framework/coordination-and-integration
Clean Architecture (Uncle Bob): https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
DDD и Use Cases: https://habr.com/ru/articles/960060/
Архитектурные опции и паттерны: https://architectelevator.com/architecture/architecture-options/
LangFlow (No-code LLM пайплайны): https://github.com/langflow/langflow
Семинар о «грязных проблемах»: https://pmc.ncbi.nlm.nih.gov/articles/PMC8918592/
Влияние AI на HR (arXiv): https://arxiv.org/pdf/2407.20371
Обзор микросервисных интеграций Sam Newman: https://martinfowler.com/bliki/IntegrationDatabase.html
Telegram API шифрование и безопасность: https://core.telegram.org/api/end-to-end
Децентрализованные мессенджеры: https://keet.io/
Open source traffic DB: https://github.com/OpenTransitTools/trafficdb
Канал архитекторов с обсуждениями: https://t.me/ru_arc_chat
Для команд до ~200 человек вполне эффективен модульный монолит.
Микросервисы оправданы лишь для больших распределенных команд с высокой сложностью.
Ключевые полезные ссылки
AWS инциденты: https://health.aws.amazon.com/health/status
Rob Pike о Lisp: https://github.com/robpike/lisp
История CLU — прототип ООП: http://www.pmg.lcs.mit.edu/ftp.lcs.mit.edu/pub/pclu/CLU/3.Documents/clu-history.PDF
RedHat о Tekton vs Jenkins: https://www.redhat.com/en/blog/tekton-vs-jenkins-whats-better-cicd-pipelines-red-hat-openshift
Prow — CI/CD для Kubernetes: https://docs.prow.k8s.io/docs/overview/
Модель управления рисками (CMU): https://www.sei.cmu.edu/documents/5836/Continuous_Risk_Management_Guidebook.pdf
Feature Flags на Go: https://github.com/thomaspoignant/go-feature-flag
Toggly — блог по feature flags: https://toggly.io/
Less Framework (coordination and knowledge sharing): https://less.works/ru/less/framework/coordination-and-integration
Clean Architecture (Uncle Bob): https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
DDD и Use Cases: https://habr.com/ru/articles/960060/
Архитектурные опции и паттерны: https://architectelevator.com/architecture/architecture-options/
LangFlow (No-code LLM пайплайны): https://github.com/langflow/langflow
Семинар о «грязных проблемах»: https://pmc.ncbi.nlm.nih.gov/articles/PMC8918592/
Влияние AI на HR (arXiv): https://arxiv.org/pdf/2407.20371
Обзор микросервисных интеграций Sam Newman: https://martinfowler.com/bliki/IntegrationDatabase.html
Telegram API шифрование и безопасность: https://core.telegram.org/api/end-to-end
Децентрализованные мессенджеры: https://keet.io/
Open source traffic DB: https://github.com/OpenTransitTools/trafficdb
Канал архитекторов с обсуждениями: https://t.me/ru_arc_chat
GitHub
GitHub - robpike/lisp: Toy Lisp 1.5 interpreter
Toy Lisp 1.5 interpreter. Contribute to robpike/lisp development by creating an account on GitHub.
👍4🤔2🔥1
Forwarded from ScrumTrek
Media is too big
VIEW IN TELEGRAM
IT-тренды 2026
📹 Короткое видео о том, куда движется IT-индустрия: какие тренды перестали быть хайпом и превращаются в новую норму, а какие только набирают обороты.
💡 Основная мысль – мы начинаем смотреть на архитектуру как на инструмент выживания и роста компании и перестаем воспринимать ее как просто набор паттернов.
Приятного просмотра, делитесь своими мыслями в комментариях!⬇️
📹 Короткое видео о том, куда движется IT-индустрия: какие тренды перестали быть хайпом и превращаются в новую норму, а какие только набирают обороты.
Приятного просмотра, делитесь своими мыслями в комментариях!
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7🤨4😐2
Подскажите в комментариях, пожалуйста, какие вам известны коммерчески успешные продукты, созданные ИИ?
Игры, приложения, что угодно, доступное публично и коммерчески успешное (или хотя бы просто публично).
Краткое исследование не позволило мне пока найти ни одного, но, возможно, я не там или не то искал.
Игры, приложения, что угодно, доступное публично и коммерчески успешное (или хотя бы просто публично).
Краткое исследование не позволило мне пока найти ни одного, но, возможно, я не там или не то искал.
🤔5❤1👍1
Новый кейс в архитектурных этюдах и… это случилось!
Тема «Архитектура управления проектированием в гражданском строительстве»
Буквально, alma mater 🙂
Подключаемся, автор кейса в канале, ответит на любые вопросы, кейс выглядит очень интересным и масштабным, так что не исключаю возможность проведения очного митапа 🙂
https://t.me/archicases/1/8326
Запрос:
— какие сложности в реализации видит сообщество;
— что бы поменяли в предложенной архитектуре.
Тема «Архитектура управления проектированием в гражданском строительстве»
Буквально, alma mater 🙂
Подключаемся, автор кейса в канале, ответит на любые вопросы, кейс выглядит очень интересным и масштабным, так что не исключаю возможность проведения очного митапа 🙂
https://t.me/archicases/1/8326
Запрос:
— какие сложности в реализации видит сообщество;
— что бы поменяли в предложенной архитектуре.