DDDevotion

@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](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

Двойная концентрация Кириллов в эфире! https://www.youtube.com/watch?v=03FnrgYLkV8 @mokevnin и @kirill_vet обсудили DDD, Event Storming и все вокруг

Очередной модуль Стратоплана идеально лег по таймингу на инфоповод от Аэрофлота: обсуждали ИБ. Без особой глубины и в целом с этой областью я знаком (даже как-то вел инфобез в региональном вузе 🥸). Синтезируя стратоплановские знания и мои хотел бы выделить заблуждения и важные моменты: Частые заблуждения (например их можно встретить в постах людей, никак несвязанных с ИБ)

1. Взлом — значит безопасники недоработали/неквалифицированные!

Конечно же это не так в общем случае. Безопасность это всегда трейдофф: бюджет, удобство, регуляторка и прочее.

2. Можно построить 100% защиту! 

Нет, нельзя. Всегда остаются учтенные и неучтенные риски.

3. У нас в компании меняют пароль 300к раз в секунду, а у них три года не меняли: вот он руткоз!

Нет, современная защита многослойная и многофакторная. Даже зная пароль, надо получить доступ к машине куда его вводить, а после получить доступ к ресурсам. Нормальный мониторинг должен заметить, что гендир в три часа ночи зачем-то начал скачивать всю документацию. Ну и доступа к инфраструктуре этот пароль вряд ли имеет. Что важно знать разработчику/менеджеру про ИБ: 1. Это отдельная область в которой много интересного, но и надо многое знать. Нормально, если лично вам интереснее другое. 2. Почитайте owasp, хотя бы топ 10 https://owasp.org/www-project-top-ten/) Если занимаетесь использованием ЛЛМ — вам отдельный топ https://owasp.org/www-project-top-10-for-large-language-model-applications/ 3. Про книги: читал только одну https://www.ozon.ru/product/zashchishchennyy-kod-1387492. Ей больше 20 лет, но базовые вещи хорошо раскрыты. Еще буквально только что попалась на глаза рекомендация этой книги https://www.manning.com/books/software-security-for-developers. Если у вас есть рекомендации — велком в комменты. 4. Развивайте комьюнити. Безопасность — это не сторонняя активность, а скорее майндсет. Это должно быть вплетено в процесс разработки от проработки фичи до конечной реализации и эксплуатации. 5. Культура открытости и доверия, психологическая безопасность позволят вам легко обсуждать проблемы с безопасностью вашего продукта, а не всячески прятать (в случае когда начальник страшнее злоумышленника). 6. Если у вас есть баунти программа и внешний аудит — делитесь результатами (если, конечно, с предыдущим пунктом нет проблем. На одном из прошлых мест наш верховный инфобезопасник (Саше привет 👋) делал пятничный дайджест задетекченных атак, находок сканнеров и баунти — разработчики очень включались. 7. Обучение, обмен опытом — мастхев. Достаточно динамичная область, постоянно выходит новый тулинг (как для атаки, так и для защиты), новые атаки, новые уязвимости. Кому-то надо держать руку на пульсе и опылять остальных. #обучение