☝️ Коллеги, хотелось бы напомнить, что у канала есть группа: @ru_arc_chat , в которой тонны полезной информации. Добавляйтесь.

Краткое содержание обсуждений
1. Языки программирования и их история
Lisp и его диалекты (Scheme, Common Lisp) — фундамент для многих современных языков (Ruby, Java).
История сборщиков мусора, роль CLU как предтечи ООП.
Анализ решений Билла Джоя с участием Гая Стила.
Ссылки:
https://github.com/robpike/lisp
https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)
https://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 и уроки их отказоустойчивости.

12. Дискуссии по микросервисам и монолитам
Для команд до ~200 человек вполне эффективен модульный монолит.
Микросервисы оправданы лишь для больших распределенных команд с высокой сложностью.
Ключевые полезные ссылки
AWS инциденты: https://health.aws.amazon.com/health/status
Rob Pike о Lisp: https://github.com/robpike/lisp
История CLU — прототип ООП: https://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.iss.one/ru_arc_chat

Подскажите в комментариях, пожалуйста, какие вам известны коммерчески успешные продукты, созданные ИИ?

Игры, приложения, что угодно, доступное публично и коммерчески успешное (или хотя бы просто публично).

Краткое исследование не позволило мне пока найти ни одного, но, возможно, я не там или не то искал.

Новый кейс в архитектурных этюдах и… это случилось!

Тема «Архитектура управления проектированием в гражданском строительстве»

Буквально, alma mater 🙂

Подключаемся, автор кейса в канале, ответит на любые вопросы, кейс выглядит очень интересным и масштабным, так что не исключаю возможность проведения очного митапа 🙂

https://t.iss.one/archicases/1/8326

Запрос:
— какие сложности в реализации видит сообщество;
— что бы поменяли в предложенной архитектуре.

Сам чатгпт говорит:

Чистый код (поддерживаемый, понятный, реализующий чистую архитектуру и Domain model) код будет нужен, и, более того, ценность «богатой» доменной модели и чистой архитектуры в ближайшие годы, скорее всего, вырастет, а не исчезнет. Изменится не сама идея, а инструменты вокруг неё: как модель описывается, проверяется и как из неё генерируется документация и вспомогательный код.

Spec‑driven / doc‑driven подходы становятся популярными именно потому, что спека становится тем, что «ест» ИИ для генерации кода и тестов.

Одновременно развивается и обратный вектор: инструменты, которые строят спеку и документацию поверх уже существующего domain model (код‑first), чтобы разные команды могли понимать и использовать модель.

Для сложных продуктовых доменов и длинноиграющих систем бизнесу нужны: стабильные инварианты, предсказуемое поведение и возможность быстро менять правила без переписывания всего окружения — это ровно то, что даёт хорошо спроектированный доменный код.

По мере роста роли ИИ именно строгий и чистый доменный слой становится «опорой» для генерации A/B‑тестов, сценариев, спецификаций API и прочих текстов: модели проще учиться и проверяться на базе кода с явными инвариантами, чем на «грязном» скриптовом зоопарке.

Если упростить: вкладываться в чистый, выразительный доменный код сейчас рационально; горизонт 5–10 лет выглядит как мир, в котором хороший доменный слой — это главный актив, на который уже «навешиваются» ИИ‑спеки, генерация документации и экспериментов, а не наоборот.

Катастрофа была неизбежна | GEO
https://www.youtube.com/watch?v=l_QcNZqUyN4

Я считаю, что это видео обязательно к просмотру каждому инженеру, это крутейший разбор аварии Челенджера. Я сам вначале был скептически настроен, но оно в итоге осталось настолко крутым, что решил разместить здесь.

Здесь и:
- Тема урезания скоупа для mission critical
- Придуманные цифры для оценки вероятности отказа
- Бюджетные войны
- Политика
- Пренебрежение безопасностью

В общем, я гарантирую, что будет интересно.

Эпистемическая диверсификация в мультиагентных системах

Некоторое время уже обсуждаю такую мысль в некоторых кругах.

Чтобы использовать курсор нужно забыть как писать код и использовать спек дривен вообще не глядя в код.

Потому что я вот детально уже описываю и он генерит рабочий и годный код, но либо с уязвимостями, либо с такой, который явно упадет при немного некорректных данных.

Код насквозь в ошибках разного рода и чем кода больше, тем больше ошибок.

При этом компилируется, работает, все в порядке…

Оно даже часто набор докер-файлов сгенерить не может так, чтобы специалист по делу не придрался.
Все работает, но специалист видит, в каком случае упадет и вероятность этих случаев стремится к 100% по мере эксплуатации.

——
Одно из решений, - это мультиагентные системы, но и они в экспериментах не решали обозначенной выше проблемы.

Я где-то месяц размышлял на эту тему, - ну мы же видим, мы же знаем, мы же можем.

И сегодня, кажется, понял. В мультагентной системе разработки агенты должны обучаться до достижения требуемого уровня (senior, middle, junior) разработчика, но на немного разных источниках. Так, как обучаются люди. У людей разная траектория развития и разный опыт. Это делает живую команду устойчивой и сильной.

Получается 7 разрабочтиков агентов с эпистемической диверсификацией, – опыта, навыков, знаний. Включая некоторый набор общеобразовательных знаний.

Остается сложность прослойке формирования общей ментальной модели, видимо оркестратор должен выступать фасилитатором для взаимного обучения в определенных областях, но эта мысль еще не настоялась. И вот такие агенты будут писать, реаьюить друг за другим и немного по-разному обучаться.

Почему эта мысль не пришла ранее? Потому что 90% всех работ, статей, кейсов, существующих сейчас - про узкую специализацию агентов, выполняющих свою функцию, и это рабочий подход для детерминированных систем, но не интеллетктуальных стохастических.

То есть мы собираем команду как настоящую команду, с разнообразием, но они в условно случайном порядке выполняют разные функции, обладая при этом полным контекстом знаний обо всех внутрикомандных функциях.

Давайте попробуем глубоко обсудить эту мысль. Я и сам уже вижу много сложностей с ее реализацией (например - само последовательное обучение + на чем именно обучаться и, что самое главное – «разобучение»), но хотелось бы послушать больше мнений.

Почему микросервисы – это сложно?

Это диаграмма 2018-го года. Обратите внимание на прямоугольники ближе к центру и дальше от него.

Чем дальше – тем конкретнее, лепестки – конкретные технологии. И с 2018-го года часть из них изменилась. Но то, что ближе к центру – остается стабильным.

Знание технологий не дает понимания или знания в микросервисах, оно дает знание технологий, которые помогают технически обеспечить работу микросервисного решения.

Это никоим образом не обесценивает знание технологий, они нужны, но только знание технологий, конкретных продуктов, ну никак не позволит спроектировать микросервисную архитектуру. Шанс случайно получить решение, обладающее всеми свойствами микросервисного архитектурного стиля стремится к нулю.

Почему agile-это сложно?

Презентация 2017-го года, разъясняющая принципы agile-манифеста. Публично в первый раз выкладываю, менять не стал ничего, все по-прежнему актуально, хоть мы и продвинулись вперед.

Здесь я раскрывал принципы манифеста для лидеров команд и самих команд, много проговаривал и отвечал на вопросы, но на мой взгляд, пролистать презентацию без пояснений тоже будет полезно.

В чем ценность этой презентации?

Agile не любят не за сами принципы, а за «операции под чужим флагом», когда называя что-то agile устраивали разработчикам потогонку, просто сократив 1 месяц до 2 недель, не меняя толком процессы, инженерию.

Этим постом я бы хотел показать, что agile как манифест или как слово не дает практических рекомендаций или схем, – для этого у человека должны быть очень глубокие знания и понимание в области организационного дизайна, инженерии, построения процессов разработки, управления изменениями. И, внезапно, под флагом agile появилось много людей, которые в этом не разбираются или разбираются поверхностно, опять же, на хайпе, и мы получили то, что получили. Практически как с микросервисами.

Чтобы вы понимали, – иногда запуск и развитие одной команды (со снятием технических ограничений, наработкой опыта и практики, развитием инженерных компетенций, практик взаимоействия, устранения зависимостей, переходу к непрерывной поставке) могло занимать год! Но эта команда в итоге могла дать фору десяткам других команд.

У меня есть школа архитектора, загнал материалы в notebooklm, попросил сделать простой обзор «как стать архитектором», без технических деталей, ну он просто в восторг меня привел, даже решил выложить, хоть и сгенерированное.

Кто хочет стать архитектором – точно будет полезно.

Формализация DDD

В обсуждениях DDD в пабликах часто можно встретить аргументы, мол DDD не конкретен, надуман.

Напишу этот пост, чтобы скидывать ссылку, а не писать каждый раз заново.

Кому хочется формальных моделей, welcome:

Z Notation:

https://www.cs.umd.edu/~mvz/handouts/z-manual.pdf

Она практически идеально сочетается с DDD и фактически дает математически строгое описание модели, полученной с помощью моделирования предметной области.

Сущности станут переменными в Z-схеме состояния, их атрибуты - типами переменных, инварианты - предикатами, а события и команды - z-схемами операций.

Схемы состояния моделируют спецификацию состояния агрегата

Z Notation формально валидируемая.

Аспекты проектирования (транзакционность и подобное) Z не поддерживает, так что использовать можно в связке:
- Z специфицирует корректность логики доменной модели
- Aggregates обеспечивают согласованность времени выполнения.

Очевидно, что проектирование - кросс-дисциплинарно в своей основе и одной формально моделью не обойтись.

Можно и использовать расширение Z-Object для Z-Notation.

Можно прикрутить еще TLA+ для агрегатов, это еще одна формальная спецификация:
https://lamport.azurewebsites.net/tla/tla.html

Многое в DDD - это рекомендации, рекомендации не формализуемы.

Формализовать до определенного уровня можно тактические паттерны, но не стратегические, да и не к чему это.

Однако возникает другой вопрос к любителям все формализовать, - а вы сами-то формальными моделями пользуетесь в повседневной работе? Проще и полезнее с прикладной точки зрения разобраться в DDD, который кросс-дисциплинарен или в паре формальных логик, выражение которых в отличие от модели Event Storming или диаграммы контекстов больше никто не поймет?

Давайте уж лучше использовать полезные, широко применяемые инструменты, чтобы двигать индустрию вперед, а не пытаться показаться самыми умными через употребление умных слов, которые несмотря на всю правильность, в прикладном ключе усложняют жизнь в широком смысле.

И я не против формальных методов, но там, где они приносят реальную пользу, а не для попыток за счет их существования обесценить другие полезные методы и подходы.