Разом всем отвечу – я не имею отношения к Сберовскому Arch.Meetup и то, что стилистика и название совпадает, - ну вот такой организаторы Arch.Meetup выбрали, стилистика ArchDays не менялась ни разу за 6 лет :)

Ловите 🙂
https://www.youtube.com/watch?v=rH3u9DvOlPk

ArchDays

1 ноября пройдет конференция ArchDays. Мы продолжаем отбор выступлений.

Темы выступлений:
- Процессы проектирования
- Практики проектирования
- Инструменты проектирования
- Обучение архитектуре
- Собственная разработка

Как и прежде есть желание сделать упор на практическую деятельность: порешать архитектурные кейсы, провести архитектурную Ката, собрать архитектурное видение новых концепций архитектуры.

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

Ссылка: https://archdays.ru

Если кого-то хотите увидеть на конференции, пишите в тред, отправлю персональное приглашение.

Увидимся на ArchDays!

Репост привествуется :)

Поделитесь собственным опытом применения AsyncAPI, особенно с какими сложностями столкнулись на старте и при развитии API
https://www.asyncapi.com/

Продолжаем набор :)

20 августа 19:00 по мск “Learning Domain-Driven Design Часть III. Применение DDD на практике (Глава 10-13) / Сергей Баранов”

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

В обсуждении нам поможет невероятный гость - Сергей Баранов 🔥 Занимается развитием направления DevOps и ИТ-архитектуры, партнер ScrumTrek с 2015 года. Он является основателем и идейным вдохновителем конференции ArchDays, председателем РОО «Объединение ИТ-Архитекторов», а также признанным экспертом в практике проведения сессий Event Storming.

Подключайтесь в вторник в 19:00 к обсуждению в Zoom или к YouTube трансляции

А в комментариях к этому посту оставляйте свои вопросы, которые хотели бы задать Сергею ⤵️

Тут продолжение :)

https://www.tgoop.com/ru_arc/445

Давайте опытом друг с другом поделимся.

Записи с ArchDays теперь доступны и в vkvideo
https://vkvideo.ru/playlist/-184472537_4

Давно не писал, накину холивар.

Архитектура – это про решения, про выбор. Когда kafka не просто не нужна, но может быть плохим выбором и источником костылей?)

- например, в логировании или когда сообщения приходят редко, то есть нет потребности в в высокой пропускной способности; тут можно посмотреть на rabbit, redis.
- нужная очень низкая latency (1-5ms), например в чатах, на биржах, – здесь альтернативами могут быть nats, zeromq, rabbit
- не нужно долго хранить сообщения (например, для истории), например, в уведомлениях, – можно тот же redis streams взять (но тут есть нюансы)
- одно из моих любимых – когда нет (и не предвидится) квалифицированых кадров для настройки и поддержки, тоже можно взять попроще – nats, redis; часто следствие этой проблемы – это попытка закрыть не оптимальные настройки и инфраструктуру техническими решениями в сервисах, в коде приложений
- нужна динамическая маршрутизация (и вообще реализация EIP из коробки для снижения уровня сложности реализации всей системы), здесь rabbit или nats подходят лучше. приходилось видеть и в живую и на выступлениях, как брали кафку, а потом сообщения проходили через несколько «служебных» сервисов, которые в себе содержали реализацию тех самых интеграционных шаблонов и это сильно сильно повышает сложность всей системы в целом

То есть kafka идеально вписывается при высокой нагрузке с долговременным храением сообщений и потоковой обработкой, но, очевидно, такие требования предъявляется не то, чтобы всегда 🙂

Call for papers на ArchDays, ждем ваших заявок на выступления, подавать тут: http://archdays.ru

Я сейчас активно применяю AI в PDLC, так как канал архитектурный, поделюсь наблюдениями в части архитектуры на основе проектов с клиентами.

1. Мусор на входе - мусор на выходе. AI анализирует данные и здесь очень большая проблема. Сейчас же только ленивый не идет в AI и с чем сталкивается сразу на входе? Либо данных нет, либо они в ужасном состоянии, либо они с огромными пробелами, разбросаны, в итоге мы получаем фрагментированный и непригодный контекст. Если раньше можно было отложить на второй план управление тех долгом, не уделять должного внимания документации, то теперь, если вы хотите получить преимущество от использования AI, придется эти долги отдавать, иначе он выдает какую-то глупость. А отдать этого долг AI никак не помогает, у него просто нет входной иформации. И вот мы начинаем проводить event storming, архитектурые воркшопы, архитектурную базу знаний (структуру документации), чтобы ее можно было начать использовать с AI и только после этого (не совсем только) получить значительный эффект.
2. Для архитектуры очень важен бизнес-контекст, а он обычно тоже слабо описан. Структурированное описание бизнес-требований, с метриками и бизнес-архитектурой тоже становятся достаточно важными. Еще очень важным становится качественный discovery-цикл. AI может прекрасно обрабатывать со всех сторон результаты интервью клиентов, но если интервью проведено плохо – ничего не поможет, поэтому навык проведения интервью (а тут уже AI особо не поможет) тоже достаточно важен. Опрос AI в некоторой роли тоже не сильно помогает, потому что у каждой компании свой контекст, который публично не транслируется за пределы компании того, с кем проводите интервью.
3. Все-таки AI в ближайшее время на заменит архитектора, политику никто не отменял. Он даст гипотезы, подсказки, кучу материалов, но окончательное решение, валидация и ответственность будет все равно за архитектором, поэтому развитие архитектурных скилов критически важно (да, и навык критисеского мышления становится еще более важным, потому что AI порой выдает очень уверенно и обоснованно чепуху). Сильного архитектора, если у него в материалах порядок и у бизнеса в материалах порядок AI действительно очень сильно усиливает, проверено.

В общем, очень похоже на микросервисы. Микросервисы - это архитектурный стиль, один из многих. Чтобы спроектировать хорошее микросервисное решение, нужно хорошо понимать фундамент архитектуры, проектирования распределенных систем и DevOps и микросервисы тогда становятся всего лишь одним из стилей в арсеналей архитектора. С AI выглядит точно так же. Так что потребность в базе никуда не делась, а, видимо, стала даже более важной, иначе мы рискуем получить тысячи нерабочих решений и экспоненциальный рост техдолга.