DDDevotion

Еще один прекрасный бандл, в этот раз от O'Reilly

https://www.humblebundle.com/books/software-architecture-2025-oreilly-books-encore

Сейчас все пытаются использовать LLM для ускорения разработки. Зачастую инструменты просто встраиваются ровно там где был человек. Это простой путь, но не всегда верный.

Возьмем код ревью (как бы мы к нему не относились). Есть, например, Code Rabbit, который подключаются к гитхабу-гитлабу и при создании пулл реквеста (мерж реквеста, кому как привычнее) оставляет свое веское мнение насчет кода. Классический код ревью как его делает человек.

Что здесь не так:
Мне всегда казалось, что такой код ревью можно сделать ДО коммита на локальной машине! Ведь результат, по-хорошему, нужен только автору кода и нужен прямо здесь и сейчас на каждый коммит, иначе у нас получается слишком длинная петля обратной связи и мусорные коммиты в репе (не все любят стешить).

Было приятно узнать, что не я один так думаю и команда копайлота сделала именно такой код ревью https://docs.github.com/en/copilot/how-tos/use-copilot-agents/request-a-code-review/use-code-review

@Drsnvld опубликовал статью на Хабре https://habr.com/articles/975936/
Фидбек, вопросы, комментарии — велкам 🙏

Если вдруг так вышло, что вы все прочитали, то вышла новая книга https://www.oreilly.com/library/view/domain-driven-transformation/9798341640108/

Судя по содержанию и введению выглядит очень интересно

Внезапно попал в мир мультитенантных архитектур. Раньше особо не работал, было только какое-то поверхностное понимание.

Тенант - группа пользователей, которые объединены общим контекстом. Например все пользователи организации могут образовывать тенант. У каждого тенанты свой (до какой-то степени) набор ресурсов и деплой.

Для чего обычно идут в мультитенантные архитектуры:
1. Безопасность. Данные разных тенантов разделены физически (с поправкой на облака, но граница достаточно явная). Данные никаким образом не могут перетечь из одного тенанта в другой.
2. Перформанс. Если у нас есть требовательный по ресурсам клиент, мы его изолируем, наливаем доп ресурсы и он получает нормальную производительность при этом остальные не страдают от его нагрузки.
3. Кастомные модели поставки. Мы можем для разных тенантов иметь различные версии нашей системы+ какие-то доработки под клиента.
4. Расширенный контроль со стороны клиента. Мы можем дать доступ к логам, метрикам, не волнуясь что мы раскрываем сенсетив данные. Это не он-прем, но может быть очень близко по уровню контролируемости со стороны заказчика.

Минусы.
1. Наверное основной минус — это стоимость. Для каждого тенанта вы создаете новый стенд, оплачивая ресурсы.
2. Второе: это сложнее деплоить, мониторить и поддерживать. Каждый релиз вы раскатываете на каждый тенант, каждую джобу для, например, восстановления данных после сбоя — вы запускаете на каждом тенанте.

И задачка со звездочкой — интеграция. Предположим, есть внешний сервис, который умеет дергать вебхук с каким-то пейлоадом. Вам надо доставлять этот пейлоад до тенанта по определенным правилам (самое простое: пейлоад содержит id тенанта получателя). Два основных подхода:
1. в лоб, регистрировать вебхук для каждого тенанта.
2. создавать роутер, который будет на основе какой-то логики перенаправлять пейлоад конкретному тенанту. Этот подход гибче, но требует доплнительных затрат на разработку и поддержку.

Много интересного на этом пути. Кстати облачные провайдеры с удовольствием делятся свои опытом. Поделитесь и вы своим 🙏

https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/overview
https://aws.amazon.com/solutions/guidance/multi-tenant-architectures-on-aws/

Вчера стартанул Advent of Code 2025. Легкое развлечение на стыке математики и разработки. Если есть желание — присоединяйтесь по коду 5146453-917f4767 Let's fun!

Один из самых недооцененных подходов в индустрии это BDD. У меня было несколько мест, где использовали бдд в той или иной степени и это был исключительно хороший опыт.

Да, это не просто. Требует понимания и трудозатрат. Но результат стоит того:

— зафиксированные договоренности с бизнесом
— снижение когнитивной нагрузки
— понятные и поддерживаемые автотесты и много другое.

Сегодня Seb Rose и Gáspár Nagy поделятся своим видением проблем и подходов при использовании BDD. Можно просто смотреть, но можно и зайти в мит, позадавать вопросики (надеюсь)

https://virtualddd.com/sessions/patterns-of-bdd-automation-a-fireside-chat-with-seb-rose-and-gaspar-nagy/

Раз пошла такая пьянка с тире и прочим — вот дисклеймер:

Я регулярно использую и планирую продолжать использовать LLM для написания постов.

Но я не постил и не собираюсь постить результат генерации напрямую. Я как минимум внимательно вычитываю, но обычно заметно переписываю текст (причем сперва несколько раз корректирую промптами).

Основные кейсы:
1. Сгенерить связки. Иногда у меня в голове из А гладко следует Б, но в тексте чувствую «прыжок» мысли — прошу ллмку сгенерить переход.

2. Генерация псевдокода.

3. Генерация финального предложения.

4. Ресерч данных.

5. Фактчекинг и редакторская правка моей писанины.


PS. При написании дисклеймера ни одна LLM не пострадала использовалась

Бонусный модуль «Идентичность руководителя» в школе СТО Стратоплана оказался неожиданно крутым.
Несмотря на странное название, это не про коучинг или философию, а про внутреннюю опору, когда вокруг всё меняется: проекты, роли, команды.

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

И, пожалуй, главный инсайт: я — разбитое сердце Джека больше, чем мои роли.
Роли могут меняться, но остаётся тот, кто их (осознанно? не всегда!) выбирает и соединяет в одно целое.

Сегодня была интересная дискуссия про soft delete (ака мягкое удаление, но мне не нравится как это звучит на русском).

Что такое soft delete и как обычно его реализуют? Если мы говорим про sql базы данных, то обычно добавляют колонку is_deleted (и в довесок всякие deleted_at, deleted_by) и вместо DELETE FROM table_name where id =@id используют UPDATE table_name SET is_deleted=true where id = @id. Кроме этого во всех запросах (как минимум на чтение) добавляют предикат is_deleted=false.

Какая польза?
1. Мы не теряем данные и можем получать более полную картинку для аудита, аналитики и прочего.
2. Если кто-то (пользователь, крон) некоректно удалил что-либо, то мы можем восстановить данные без сложных манипуляций с бекапом (которого еще может и не оказаться).
3. Есть выигрыш по перфомансу на массовых операциях удалени.

Минусы тоже есть:
1. Код сложнее, надо не забывать везде отфильтровывать.
2. Перфоманс может страдать, если записей в таблице много и процент is_deleted достаточно большой, то надо будет что-то придумывать дополнительное (самое простое индекс по полю is_deleted).
3. Может пострадать доверие пользователя -- я не рекомендую (в общем случае) использовать soft delete на реально чувствительных для пользователя данных без дополнительных механизмов гарантии невосстановления.

Иногда приходит требование реализовать пользовательскую логику удаления/восстановления в корзину. И часто есть соблазн переиспользовать механизм soft delete для этих целей:
1. Удаление в корзину через set is_deleted=true
2. Восстановление через set is_deleted=false
3. Получение списка сущностей в корзине -- выборка с предикатом is_deleted=true
4. Удаление из корзины через hard delete.

Вроде все норм, разработчик ушел делать.

Но если посмотреть на это через призму DDD? Если обобщать, то у нас есть технические (инфраструктурные) решения и решения продиктованные бизнес-логикой.

1. Технические решения должны быть простыми (насколько это возможно), ничего не знать про бизнес-логику, не подвергаться регулярным изменениям, быть общими для всех сущностей.
2. Имплементация бизнес-логики наоборот должна максимально много знать про то что происходит и следовать этому знанию в том числе в нейминге: удалено, в корзине, скрыто, дезактивировано -- все это выглядит похоже, но несет различную смысловую нагрузку.
3. Бизнес-логика обычно чаще меняется и имеет тенденцию к усложнению: со временем нужно будет дать права на просмотр корзины и восстановление, необходимо будет учесть время или еще какие-то признаки.
4. Многие сущности будут требовать и технического решения и бизнесового: например даже после удаления из корзины, мы хотим иметь доступ к сущности для аудита.

Soft delete это техническое, в первую очередь, решение. Удаление в корзину, это решение которое продиктовано бизнес-логикой. Я категорически не рекомендую смешивать такого радо механизмы, как бы они не выглядели похожими.

Завершился пятый модуль в Школе СТО в Стратоплане (хотел написать что и обучение, но внезапно накинули бонусный модуль про самоидентификацию руководителя).

Последний модуль не был каким-то цельным, скорее сложили все темы, которые нужны, но до этого не влезли:

1. Контракты-закупки-подрядчики
2. Работа с ключевыми сотрудниками
3. Работа с ключевыми стейкхолдерами, в первую очередь с СЕО

Контракты. Важная часть работы СТО, было интересно послушать, но так как я особо не касался этой области в работе - не хватило инсайдов. Как то все было обще (типа рассрочка платежа это хорошо, если мы платим, если рынок поставщика, то он и диктует условия и тп). И еще не хватило какой-то ситиошной специфики, кажется она есть.

Второй день про удержание ключевых сотрудников и в целом про мотивацию. Было полезно освежить знания. Местами спорно, но было полезно.

И последний день был про общение с СЕО и другими большими ребятами. По сути нет особого рецепта, главное знать, что каждой аудитории нужен свой формат. Три года назад на книжном клубе у Саши Поломодова мы как раз обсуждали главу Communicating the strategy из книги Technology Strategy Patterns -- многое перекликается (ссылка в первом комментарии).

В целом про школу даже не могу сказать однозначно: стоит идти или нет. Местами не хватило консистентности, где-то были знания внахлест, где-то повторы, где-то я и так знал много, а что-то мне не очень релевантно. Как вариант -- дать студентам больше гибкости в выборе траектории.

Интересно, что Слава Панкратов (СЕО Старатоплана) недавно устроил опрос в Линкедине, видимо модулируя как раз сравнение "школы" против одного курса:

Быстрый опрос: на какой курс вы реально быстрее себя уговорите?

1 навык, 1 мес, 700 евро -- 78%

10 навыков, 5 мес, 2500 евро -- 19%

Но точно могу сказать, что Стратоплан дает хороший управленческий минимум, а с другими подобными русскоязычными школами я не знаком вовсе. Так что решение "идти-не идти" очень зависит от обучающегося. Если вы вначале управленческого пути, то вполне себе вариант, про их тимлидский курс, например, слышал много хороших отзывов. Ну и отдельные курсы (я был на Финансах, Найме, Стратегии) очень полезные и хорошие.

#обучение

Смотрите .net days от JetBrains? Очень много интересных (по названию как минимум) докладов. Вчера было про чистую архитектуру, а прямо сейчас идет доклад про версионирование при использовании event driven подхода

https://www.youtube.com/live/Aq1xHunHNuA

Делитесь, если что-то вас зацепило!

че-т мы давно реальные DDD-кейсы не разбирали.
никому ничего не нужно смоделировать?
набросил бы кто на вентилятор...

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

Одна из веток — идея, что разработка это не только код, а социо-техническая система. Недостаточно уметь правильно рисовать контексты, проектировать модель, пилить агрегаты — всё полетит только если команды aligned.

Не знаю как вышло, но под зонтиком DDD оказался подход Team Topologies, который набирает всё больше популярности. Основная (для меня) мысль подхода: системы становятся огромными, сложность (и техническая, и бизнесовая) постоянно растёт, но головы инженеров не резиновые. Поэтому команды и процессы надо строить так, чтобы не порождать лишнюю когнитивную нагрузку.

И сегодня это тема получила новое развитие: вышло второе издание книги Team Topologies. Авторы на стриме рассказали про подход в целом и о том, что изменилось в новом издании: https://www.youtube.com/watch?v=iTSn8o6Iq7A

А вы читали книгу? Что-то пробовали в своих командах-отделах-компаниях?

Немного оффтоп, но я очень удивился новостям про Oracle. Не помню чтобы старичок рынка вырастал в полтора раза за неделю. Наверное что-то похожее было у NVidia, но это другое.

Чем же так Оракл впечатлил инвесторов? Основных драйвера вижу два:
1. Рост облачной выручки (на 28% YoY).
2. Подписанные контракты на почти полтриллиона денег. Тоже облачные, насколько я понимаю.

Облака всем нужны и корпоратам тоже, тем более Oracle помимо чистого облака Oracle Cloud Infrastructure предлагает MultiСloud DB: ораклиные стойки колоцированны в gcp/azure/aws, но весь биллинг (и остальные сервисы) остается за основным провайдером.

Но основной прирост как я понимаю произошел за счет AI хайпа. Oracle предлагает много интересного как в своей флагманской СУБД (встроенные векторные индексы и прочее), так и в IaaS (суперкластер GPU). Как следствие многие крупные ребята (openai, grok, и прочие m***) рассматривают использование OCI для своих несомненно жирных AI related нагрузок.

Прошел очередной модуль обучения в Стратоплане. Это была трехдневка финансов — наверное, самая далекая от обычной для меня деятельности. Если с людьми-процессами-технологиями начинаешь работать чуть ли не с позиции individual contributor, то с финансами у меня реальный опыт весьма ограничен. Тем было интереснее!

Что осознал нового:

1. Все модели отчеты врут, но некоторые могут быть полезны. Не то чтобы врут, но отдельные цифры в вакууме особо ничего не показывают и могут даже ввести в заблуждение. Воспринимайте отчетность, как маленький срез реальности, на основе которого можно строить гипотезы и как-то валидировать гипотезы другой отчетностью (или другим периодом).

2. Если вы совсем неопытны, то используйте ChatGPT для первичного анализа и набрасывания гипотез, подсвечивания рисков.

3. Модели это круто, но очень сложно. У нас был игровой кейс и мы с командой хотели на коленке сделать модель для учета затрат и выручки не самой сложной фирмы — не вышло (хоть и за очень ограниченное время).

4. Стартуете новое направление или стартап — накидайте простую модель, учтите жирные налоги и затраты (фот, проценты инвестору-кредитору). Можно понять сильно раньше бесперспективность идеи или перекрутить подход к монетизации.

#обучение

https://www.ohyaml.wtf/ любите ли вы ямл так как люблю его я?

Этот квиз поможет лучше понять, что не так с Норвегией и почему в мире YAML ложь легко становится истиной 😅

Сегодня День Знаний. Для меня этот праздник не только про школу или университет, а про всю жизнь.

Именно знания открывают нам новые двери и делают нас свободнее в выборе пути. Пусть у каждого будет своя жажда узнавать новое — и сила применять это в жизни.

С праздником, друзья!

Отличное погружение в DORA project от @IgorKurochkin и @apolomodov https://www.youtube.com/watch?v=paynIB-5pow

Я читал какие-то статьи, листал Accelerate, но никогда системно не погружался внутрь. С удивлением открыл для себя обширный новый мир.

Кто совсем не в курсе: проект DORA - исследовательский проект (перешедший под крыло Google Cloud некоторое время назад). Основной артефакт - ежегодный отчет Accelerate State of DevOps Report в котором на основе опросов выявляются различные тренды и инсайты.

Этот репорт появляется на основе модели DORA Core, где собраны проверенные временем практики, метрики и результаты (outcomes - не знаю хороший аналог на русском). Модель - это скорее ориентир: она помогает командам расставлять приоритеты и двигаться в сторону постоянных улучшений, опираясь на исследования.

А вы используете какие-то модели внутри: dora, devex еще какие-либо?

Когда-нибудь у меня будет пара часов посмотреть внимательно выступление и походить по ссылкам и референсам. А пока просто прикопаю это здесь https://www.youtube.com/watch?v=wo84LFzx5nI