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

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://t.me/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