Материалы про Event Sourcing + Specs Для тех, кто уже работает с исполняемыми спеками или еще только хочет начать слезать с Open Spec и хрупких спеков в виде markdown. Или просто интересуется event sourcing. Это та теоретическая база, которую я использую при разработке продуктов и проектов с бизнес логикой сейчас - в 2026 году. Просто потому, что coding агенты работают потрясающе хорошо с исполняемыми спецификациями. Содержание: Fundamentals - основы Why Event Sourcing? - преимущества Aggregates - как организовывать бизнес-логику Projections - как работать с views и БД в целом Specifications - как тестировать логику Versioning - как версионировать и развивать систему Event Storming - методика воркшопа для моделирования в команде Материалы открыты для всех (регистрация не нужна). Читать можно тут. Ваш, @llm_under_hood 🤗

Октябрь ворвался в нашу жизнь, разрушив планы на сентябрь 😀 Свел в кучку некоторые материалы, над которыми я усердно трудился. Я ведь пишу посты без ИИ, вот этими вот руками. Поддержите меня какой-нибудь реакцией 🙏🏻 Что там с ИИ ▪️Сейчас в мире ИИ обновления сыпятся почти ежедневно, уже внимание к ним ослабло, но за топовыми моделями следим тут и тут. ▪️Еще вот тут писал про новый класс моделей, очень быстрых в классификации. Сейчас, кстати, такие стали появляться и в опенсорсе. ▪️Чего ждать от ИИ до конца десятилетия - тут. Подходы и процессы ▪️Метод Event Storming для изучения командой бизнес-доменов ▪️Постановка задач с помощью EARS ▪️Поиск бутылочных горлышек в процессах с помощью теории ограничений В помощь разработке ▪️Структурирование контента с помощью schema.org ▪️Нагрузочное тестирование приложений Из жизни ▪️Экономим на MS Office ▪️Путешествие мухи во все тяжкие ▪️Почему кокпиты самолетов разных цветов #summary

Когда команде разработки готовят некую новую задачу, функцию продукта, это надо сначала понять и описать. Есть такой подход для командной работы - Event Storming. Это шумное сборище интенсивный воркшоп для исследования сложных бизнес-доменов. Помогает создать единое понимание бизнеса у разработчиков, аналитиков и заказчиков. По классике это происходит на большой стене с помощью стикеров. Команда выстраивает цепочки бизнес-процессов во времени (слева направо). Стикеры могут быть такие: 🟧 События (Domain Events) — факты, которые уже произошли (глагол в прошедшем времени). 🟦 Команды (Commands) — действия, запускающие события. 🟪 Агрегаты/Системы — то, что выполняет команду. 🟨 Акторы — люди или внешние системы, инициирующие действия. Пример из жизни: заказ такси. Процесс поулчается такой: 🟨 Пассажир нажимает кнопку в приложении. 🟦 Команда: «Создать заказ». 🟪 Сервис заказов принимает её. 🟧 Событие: «Заказ создан». 🟦 Команда: «Назначить водителя». 🟧 Событие: «Водитель назначен». 🟧 Событие: «Поездка завершена». Зачем это нужно? 🔹 Единый язык: cтирает границы между бизнесом и IT. Все говорят на языке домена. 🔹 Поиск дыр: cразу видны пробелы в логике, дублирование функционала и узкие места. 🔹 Фундамент для DDD: легче начать проектирование микросервисов и Domain-Driven Design. Подробненько всё расписано тут и тут. #process