Последние посты
DDDevotion
19 авг., 14:20
Вижу в индустрии два подхода к внедрению ai разработки. Понятно, что это спектр, но в целом компании кто пробует идутлибо сверху вниз: выделяют хед оф ии, создают отдел/центр экспертизы. Эти ребята пробуют инструменты и директивно внедряют. Они же как-то измеряют эффективность и ответственны за рациональное использование бюджета.либо снизу вверх: сверху выделяют бюджет и разрабатывают политики и правила. Остальные решения отдают на откуп вниз — в юниты, команды, инженерам.На самом деле здесь нет правильного направления. Наверное, децентрализованное снизу вверх несколько лучше, но внедрение ии (как и любых других изменений в работе) требует усилий и времени на эксперименты. И в иных компаниях единственный способ это время гарантировать — огородить от всякой иной работы.А как у вас проходит/проходило внедрение?DDDevotion
13 июл., 17:06
Записываем в календарикиКогда: завтра, во вторник 16:00 мскЧто: стрим Александра Поломодова и Максима Смирнова с обсуждением Engineering loophttps://www.youtube.com/live/hnFLfiJOtQE?is=pOlF8JVWJr9mspC4YouTubeResearch Insights Made Simple #19 - разбор whitepaper"Loop Engineering" с Максимом СмирновымКто управляет кодинг-агентом: человек или спроектированный им цикл? Мы привыкли обсуждать промпты, контекст и обвязку одного запуска агента. Но когда агент сам возвращается к работе - по расписанию, событию или результату прошлого прохода, - задача становится…DDDevotion
10 июл., 17:02
Иногда наше бизнес-правило может выглядеть так: if (this.Total > 100) Мы точно знаем, как получить результат. Но понимаем ли мы, что означают эти 100 и какое решение сейчас принимает система? Можно вынести число в константу. Можно спрятать сравнение за методом с убедительным доменным названием. Но хорошее имя не появляется от самого рефакторинга — его нужно заслужить пониманием домена. Если такого понимания пока нет, простыня ифчиков будет честнее, чем красивый, но выдуманный (кодогенерация вам в помощь!) RequiresManualApproval().Имя в коде — это утверждение о нашем понимании системы.Поэтому хороший нейминг требует честного ответа: мы уже знаем смысл этого правила или пока только умеем его вычислять?DDDevotion
8 июл., 13:55
Давно не касался темы инцидентов и постмортемов.SRE Book вышла уже 10 лет назад, и может показаться, что тема давно полностью раскрыта. Но я всё равно позволю себе небольшой рекап.Хороший постмортем, на мой взгляд, держится на двух вопросах:1. Как снизить вероятность повторения инцидента? 2. Как раньше заметить, что в системе происходит что-то нездоровое?И я часто вижу в обсуждениях сильный перекос в сторону первого вопроса.После инцидента команда часто приходит к выводам вроде:надо лучше тестировать; надо больше автотестов; надо строже линтеры; надо внимательнее ревьюить; надо писать только хороший код и т. д.Все это правильно. Более того, чаще всего это действительно нужно.DDDevotion
12 июн., 07:14
Вышел LeadDev Engineering Leadership Report 2026Как же быстро ИИ в разработке прошел путь от “давайте попробуем” до обычной управленческой повестки. В отчете хорошо видно, что компании уже не столько решают, нужен ли им ИИ, сколько пытаются понять, что теперь со всем этим делать. Пока основной разговор все еще крутится вокруг продуктивности разработчика: быстрее написать код, быстрее собрать прототип, быстрее закрыть задачу.Но также виден следующий слой. Менеджеры/техлиды хотят: Управлять агентами Координировать автономные системы. Понимать, как вообще измерять эффект от ИИ. Разбираться, где проходит граница между помощью инструмента и ответственностью команды.То есть ИИ постепенно перестает быть просто “умным автокомплитом” и становится частью процесса разработки. И вопрос уже не только в том, как научить разработчика пользоваться новыми инструментами, вопрос в том, какDDDevotion
9 июн., 16:56изменён
Интересный взгляд на агентскую разработку через DDD-призму.А как вы работаете с агентами? Знает ли ваш агент, с каким доменом он сейчас работает? Понимает ли, в каком слое системы находится задача?Я пока часто отдаю задачу «под ключ», надеясь, что агент сам разберётся. Но если мы считаем, что кожаным разработчикам важно понимать тип домена, границы модели и слой, в котором они работают, то для ИИ это тоже важно.И, на мой взгляд, не только через явные проверки, тесты и контракты. Агенту нужно давать саму архитектурную рамку и описание частей, чтобы он сам мог подстраивать стиль изменений под этоhttps://www.linkedin.com/posts/romanov-pavel_this-article-explores-how-mature-software-ugcPost-7459876259515461632-Uh8GDDDevotion
28 мая, 16:20
Такое мы смотрим https://www.youtube.com/watch?v=K-Xv8D8NjTkЯ как дотнетчик со стажем начиная с версии 1.1 очень благодарен ему за язык и платформуYouTubeTypeScript, C# and Turbo Pascal with Anders HejlsbergAnders Hejlsberg is a living legend and one of the most influential programming language designers of all time. He created Turbo Pascal, Delphi, C#, and also TypeScript. As well as that, he spent nearly a decade at the pioneering dev tools company, Borland…DDDevotion
13 мая, 12:10
Необычный взгляд на платформы и их роль в разработке. В некоторой степени перекликается с идеей фреймворка Cynefin. Если вы в простом домене (а само по себе создание нового сервиса с дефолтным профилем нагрузки — это простой домен), то best practice (right choice, golden path) в виде платформы и принуждения ее использовать скажется позитивно.Но затаскивать платформу туда, где chaos/complex домены — это стрельба по ногам. Вот бы еще научиться легко отличать одно от другого 😅https://www.linkedin.com/pulse/%D0%BF%D0%BB%D0%B0%D1%82%D1%84%D0%BE%D1%80%D0%BC%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F-%D0%BA%D0%B0%D0%BA-%D0%BC%D1%8F%D0%B3%D0%BA%D0%BE%D0%B5-%D0%BF%D1%80%D0%B8%D0%BD%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5-evgeny-konechnyi-ajcmf/LinkedinПлатформизация как мягкое принуждениеНедавно, пока был в спортзале, наткнулся на философский подкаст про «технику» с комиками. Звучало как сомнительная комбинация, поэтому я, конечно, включил и впервые услышал тезисы французского философа Жака Эллюля.DDDevotion
28 апр., 14:08
Вслед за Антропиком, Гитхаб копайлот анонсировал новые тарифы. Формально стоимость планов не поменялась, но мякотка в множителях и они вырастут в 3-9 раз.О чем это говорит: самая частая версия в блогах— заканчиваются деньги инвесторов, надо показывать рост выручки и прочую ебитду.Но по мне, это говорит, что мы прошли стадию early adoption. Изначально вендоры "доплачивали" за использование, чтобы затащить новую парадигму: собирали сценарии, доказывали ценность, формировали привычку.Решена ли задача кодинга — нет конечно, еще много проблем, нестабильного и опасного поведения, нет еще устоявшихся паттернов использования и тд. Но что для меня однозначно: агентская разработка теперь с нами, прыгайте в этот поезд, еще не поздно!DDDevotion
1 апр., 11:07
в свете утекшей кодовой базы claude code в сети опять обсуждают применимость чистого/совершенного кода в современных продуктах.Основной тейк одной из сторон: фу таким быть, ужасный код и тп. Им в ответ пишут: ваши паттерны (ооп, солид и прочее) никому не нужны, код и так генерит тонны денег.На мой взгляд ничего нового в этом конфликте нет, ллмки и вайбкодинг просто дали еще один повод это пообсуждать.Можно ли создать прибыльный продукт без процессов, грамотных инженерных подходов на всех уровнях и всего хорошего, что описано в различных книгах от Брукса и ГоФ до Хононова и Клепмана? Конечно можно! Если вам повезло угадать нишу и время, то любой работающий код будет успешен.Но на самом деле важен другой вопрос: влияет ли качество кода на итоговый успех продукта? Раньше в целом был консенсус: да, в качественном коде меньше дефектов, проще читать и вносить изменения.Предположим,DDDevotion
6 мар., 09:54изменён
Опять про ллм- разработку.Сейчас на работе у меня сложилась идеальная ситуацияЕсть достаточно большой неизвестный мне проект на плохо известном стеке (джанга)Есть набор задач без горящих дедлайновЕсть надежные процессы, которые не пропустят дичь на продЕсть мое, как мне кажется, неплохое понимание прекрасного в разработкеИ вот чувствую себя как на эмоциональных качелях: от восторга до полного разочарования и обратно.Код он пишет и правда быстро, но с одной небольшой задачей я застрял уже на несколько итераций.Вроде все просто: надо взять токен и в бекграунд таске сходить в другую систему.Но оказалось:DDDevotion
28 февр., 08:11
в свете использования LLM для разработки людя много обсуждают покупать или строить. Если смотреть с позиции DDD, то все однозначно: generic сабдомен покупаем, core саюдомен строим сами, supporting -- как получится.Но LLM -- геймчейнджер, и теперь люди задаются вопросом, зачем нам платить за SaaS $n per months per user, если мы можем просто такой же саас навайбкодить за вечер (и пачку токенов)?Для меня ответ по-прежнему прост: можете купить зрелое решение -- купите. Дорого? Попробуйте план попроще. Все равно не по карману? Посмотрите на опенсорс!Когда вы берете готовый продукт, вы получаете не только код, вы покупаете: - некую готовую методологию решения проблемы - тонны продуманных и решенных корнер-кейсов - какую-никакую секурность - решенные инфраструктурные вопросы - потенциальное развитиеКогда все таки кодить/вайбкодить с нуля имеет смысл?1. На рынке нет устоявшихся/готовыхDDDevotion
24 февр., 08:49
Завидую джавистам в том что у них есть такие спикеры как Алексей Шипилёв (рассказывает всякое про сборку мусора) и Андрей БреславОчень интересный подкаст про котлин и как его делали https://newsletter.pragmaticengineer.com/p/the-programming-language-after-kotlinPragmaticengineerThe programming language after Kotlin – with the creator of KotlinAndrey Breslav, creator of Kotlin and founder of CodeSpeak, shares lessons from designing Kotlin and why he’s building a new language to keep humans in control in the age of AI.4,170Открыть в TelegramDDDevotion
19 февр., 17:37
Альберто Брандолини с командой выкатили паттерны для проведения Event Storminghttps://www.eventstorming.com/patterns/Рекомендую ознакомится, но кажется главная проблема теперь как позвать агентов на такой воркшопEventStormingEventstorming Patterns - EventStormingA growing selection of patterns and antipatterns to handle your workshop design and facilitation. We have been there too!DDDevotion
28 янв., 17:37
Сегодня так много интересного!!!1. Стрим с Владом Хононовым Loosely Coupled - Deep dive into coupling with Domain-Driven Design https://www.youtube.com/live/NGENigtNUck 🍾2. Дискуссия Rebecca Wirfs-Brock и Mathias Verraes https://virtualddd.com/sessions/critically-engaging-with-models-a-conversation-with-rebecca-and-mathias/ 👏3. Финальный тур ЛЧ 🙈YouTubeLoosely Coupled - Deep dive into coupling with Domain-Driven DesignWelcome back to "Loosely Coupled," the Live Stream series brought to you by BridgingTheGap.eu.com! “Context is king!” - I hear very often now, as we dive into various discussions about software architecture. “It depends” - is something I often say, and I…DDDevotion
26 янв., 14:01
В инженерных командах развитие часто пытаются рассматривать как индивидуальное качество: хочет человек учиться или нет. Кто хочет — вырастет, с остальными и возиться нечего. Мне в целом везло на коллег и компании. В большинстве случаев это были небезразличныеYouTubeМотивация, доверие и влияние в инженерных командахАся Исакова — организационный психолог (магистр Work, Organizational & Personnel Psychology) и приглашённый лектор университета Pompeu Fabra (Барселона). Почитать Асю можно в её канале Это База | Компас конгруэнтности (http://t.me/integritycompass).DDDevotion
25 янв., 09:58
Саша Поломодов запилил книгу сайт про Систем дизайн и все что около. Саша давно форсит эту тему — круто, что у него дошли руки все это скомпилировать.https://system-design.space/System Design SpaceSystem Design Space — Главная, граф знаний, треки и материалыГлавная страница System Design Space: быстрый старт, граф знаний, библиотека материалов, персональные треки и трекинг прогресса.DDDevotion
21 янв., 18:21изменён
Сейчас разбираюсь в проекте на не совсем мне привычных Python/Django. Естественно использую агенты для изучения и модификации. Поменял код, поправил, потестил, залил в репу, создал ПР, мне накидали комментов — все как обычно.Дальше я настроил в копайлоте github mcp, хотел по очереди получать правки, менять код и коммитить. Но промпт получился слишком общим. В итоге агент сам поправил весь код в соответсвии с комментами, запушил, прокомментил в пулл-реквесте через mcp. Ладно я сознательный — посмотрел коммиты, добил промптами пару вещей, которые явно не были проговорены в пулл-реквесте, дополнительно отревьювил код ллмкой и только после этого понес на повторное ревью.Но вангую, что ближайшее время люди будут именно так проходить пулл-реквесты. И хорошо если хоть на одном из этапов код откроет кожаный мешок, а не бездушная LLMDDDevotion
20 янв., 08:24изменён
В инженерных командах развитие часто пытаются рассматривать как индивидуальное качество: хочет человек учиться или нет. Кто хочет — вырастет, с остальными и возиться нечего.Мне в целом везло на коллег и компании. В большинстве случаев это были небезразличные инженеры, дизайнеры и менеджеры — люди, которые развивались сами и подтягивали людей вокруг. Я и сам через личный пример, менторство и лидерство стараюсь делать то же самое.Но на практике обучение и развитие — это не столько про личную мотивацию, но и про социальные отношения. Люди вкладывают силы потому, что считают сам процесс развития осмысленным и безопасным для себя. И одна из задач нас как лидеров (формальных или нет) — как раз придать процессу осмысленность и безопасностьХочется на стриме разобраться, как мотивация, доверие и готовность команды вкладываться связаны между собой и почему без этого даже разумные решения иTelegramЭто База | Компас конгруэнтностиОрганизационный психолог Ася Исакова Поясняю за поведение людей на работе: научно и с леопардами 🐆 Помогаю хорошим людям становиться крутыми руководителями Продаю лекции «ЭТО БАЗА» и консультирую: @asasenpai Ссылки: https://linktr.ee/isakova_asyaDDDevotion
16 янв., 17:07
Всем привет!Праздники остались позади, надеюсь, все более-менее вкатились в рабочую рутину. Много рефлексировал насчет канала: о чем писать, куда развивать, монетизировать ли, если да, то как и т. д.Я уже как-то писал, что тактическая часть DDD особо не развивается. Да, выходят какие-то статьи и даже книги, но они выглядят как компиляция прежних идей. Как будто бы мы выработали общий подход, как писать код в DDD-стиле, и пока что сообществу нечего сказать нового.Но поднимаясь выше, на уровень архитектуры — уже становится интереснее: event messaging, мультитенантные архитектуры, различные интеграции систем. Есть паттерны/подходы, которые себя хорошо зарекомендовали, но жизнь преподносит новые вызовы, которые как-то надо преодолевать.А можно заглянуть еще выше — на уровень социотехнических систем. Разработка продукта требует не только качественных технических решений, но и
