Доклад про DDD + AI в проектах (Berlin, 2025, EN) Не прошло и года с прошлого KanDDDinsky, как на YouTube выложили видео с моим выступлением с этой конференции: "When DDD Met AI: Practical Stories from Enterprise Trenches" Если во время записи кажется, что я периодически кошусь в одно место в зале - это не кажется. Там сидит Eric Evans, который обещал быть самым полным энтузиазма слушателем) Кстати, на KanDDDinsky в этом году (это будет 15 октября) я проведу двухчасовой hands-on на тему "Engineering trustworthy and testable AI agent". Кто-нибудь будет на этой конференции? А еще, кто-нибудь хочет устроить встречу LLM под капотом в Берлине вечером 14го или 15го октября? Ваш, @llm_under_hood 🤗

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

Борьба со сложностью В продолжение темы о переусложнениях, которые полюбили делать современные модели, поделюсь своими двумя скиллами, которые помогают с этой самой сложность бороться. Code That Fits in Your Head Скилл-дестиллят книги Марка Симмана, название которой говорит само за себя. Цель скилла: прежде всего, выбор понятных и сопровождаемых решений и их реализации. Начинка довольно сильно адаптирована мною под агентную разработку. Этот скилл я особенно люблю применять когда нужно реализовать какую-то хитрую штуку, которая априори сложная (из моей практики сразу в голову безопасный парсер псевдо-SQL кода, который приходит от агента и преобразуется в безопасный MongoDB query). А более бытовой пример с задачей по ускорению обхода файловой системы на скринах. Ubiquitous Language Скилл занимается обслуживанием всего, что связано с языком в проекте: 1. Генерирует и поддерживает в актуальном состоянии т. н. тезаурус (docs/THESAURUS. md) - это расширенный словарь понятий с разъяснением неоднозначностей и фиксацией чем понятие является, а с чем его не стоит путать и с какими понятиями оно связано. Кстати, помимо того, что агенты начинают лучше понимать проект, приятный бонус от тезауруса - это более точные результаты от grep'a. 2. Позволяет агенту выбирать новые имена для сущностей, сервисов и прочих артефаков с оглядкой на этот самый тезаурус и вообще агент больше думает о важности языка и нейминга. Этот скилл тоже делался на плечах гигантов: в основу был взят блок про Ubiquitous Language из отличной книжки Влада Хононова "Изучаем DDD — предметно-ориентированное проектирование", а также блоки про язык из FPF + ISO 25964 про создание тезаурусов (все сорсы тут). Оба скилла тем ценнее, чем больше и сложнее проекты с которыми вы работаете. А еще, к планированию архитектуры и вообще к тому, как наиболее элегантно встроить тот или иной функционал я люблю привлекать Fable (обычно на low или medium reasoning). И, конечно, никакой скилл не заменит понимание системы и продукты инженером. Собственно, третий этап после скиллов и Fable ревью - это фильтр через человека-инженера (на скринах как раз пример такой пирамиды из 3-х этапов как мы с агентами ищем оптимальный способ ускорить обход файловой системы: 1: анализ плана скиллами, 2: Fable, 3: инженер - это мой-вопрос финальная корректировка: заметьте, что я ее задаю в виде вопроса, давая агенту пространство для несогласия). Выбор наиболее оптимального решения из огромного пространства траекторий - это все еще сложнейшая задача для LLM. Да и для экспертов часто непростая. Почему это важно, вроде, очевидно - сложное и неоптимальное решение обычно более хрупкое - на него будет сожжено больше токенов, а в проде оно с большей вероятностью будет ломаться в разных местах (или эффектом бабочки ломать что-то смежное). Опять же, все это становится острее на масштабе: пока вайб кодишь проект на полтора пользователя, может казаться, что все и без этого прекрасно. @ai_driven

Покорение книги Эванса продолжается. Сегодня 2 и 3 главы. Вторая глава это буквально пляжный эпизод. Общайтесь на одном языке в рамках работы. Возможно это я чего то не понимаю, но рано или поздно при работе вы будете общаться на одном языке. Выработаете свои термины, придумаете определения, согласуете наименования. Даже если это произойдёт не сразу, то как будто бы это какая то базовая штука, которая на подкорке сидит. Глава третья уже по интереснее. Посыл понятен. Делайте модель вместе с кодом, код должен отражать модель, а модель код. Но некоторые заявления, как по мне бред. Во-первых, завязываться на ООП парадигме при проектировании это бред. В таком случае нам технологии начинают говорить что и как делать, а не наоборот, когда требования говорят, какие технологии брать. Во-вторых, заявление о том, что разработчики что-то там в тихую могут строить, не соответствующее модели. Возможно, во времена Эванса так оно и было, но сейчас даже в униках у большинства людей есть понимание, что так делать не надо. Что есть требования и их описание, и есть реализация.

Пока мир сходит немного с ума с нейронками по паспорту и опенсорс суверенными моделями, я решил начать читать настоящую базу - книгу Эванса по DDD. По ощущениям я снова оказался в той ситуации, где мне нужно разъяснение, а как код то писать надо. Первый раз меня подтолкнула книга "Чистая архитектура", где я понял, зачем интерфейсы вообще нужны. Пока что, прочитав 1 главу, которая посвящена тому, как говорить заказчиком про ТЗ, буквально. Мне этой проблемы не понять, может ранее программисты напрямую общались с заказчиком, а не через менеджеров, и им реально приходилось вытаскивать адекватные требования из людей. Да и не понял я момента, где он говорит, что должен быть поток обратной информации от разработчика. Однако довольно интересный момент в 1 главе есть. А именно замечание о том, что какие-либо правила системы не надо прятать в операциях, а надо выносить на уровень хотя бы методов. И делать это надо не ради расширяемости или чего-то еще, а что бы просто ментально было понятно, что тут не просто домножение на10 или деление на 3, а специальная операция для определенной цели.