Сегодня была интересная дискуссия про 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 это техническое, в первую очередь, решение. Удаление в корзину, это решение которое продиктовано бизнес-логикой. Я категорически не рекомендую смешивать такого радо механизмы, как бы они не выглядели похожими.

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

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

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

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

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

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

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

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

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

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

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


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

Один из самых недооцененных подходов в индустрии это 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/

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

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

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

Для чего обычно идут в мультитенантные архитектуры:
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/

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

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

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

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

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

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

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

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

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

Всем привет!

Праздники остались позади, надеюсь, все более-менее вкатились в рабочую рутину. Много рефлексировал насчет канала: о чем писать, куда развивать, монетизировать ли, если да, то как и т. д.

Я уже как-то писал, что тактическая часть DDD особо не развивается. Да, выходят какие-то статьи и даже книги, но они выглядят как компиляция прежних идей. Как будто бы мы выработали общий подход, как писать код в DDD-стиле, и пока что сообществу нечего сказать нового.

Но поднимаясь выше, на уровень архитектуры — уже становится интереснее: event messaging, мультитенантные архитектуры, различные интеграции систем. Есть паттерны/подходы, которые себя хорошо зарекомендовали, но жизнь преподносит новые вызовы, которые как-то надо преодолевать.

А можно заглянуть еще выше — на уровень социотехнических систем. Разработка продукта требует не только качественных технических решений, но и организационных, процессных, продуктовых и т. п. Кажется, именно здесь происходит все самое интересное. Team topologies, оргдизайн, коммуникации, презентация идей, мотивация, развитие доверия, психологическая безопасность — эти вещи могут бустануть разработку значимо сильнее, чем очередной паттерн или новая БД.

Ну и отдельной строкой идут LLM: как построение продуктов на базе AI, так и использование LLM для кодогенерации и сопутствующих процессов. Здесь тоже много неопределенности и hidden gems.

В итоге получилось несколько тем, которые хочется копать дальше:

1. Team topologies, оргдизайн, организационная психология
2. System design, архитектура
3. LLM для разработки
4. Коммуникации
5. Technical excellence

Если честно, то последние посты и так были не столько про DDD в чистом виде, сколько про то, что вокруг него и над ним. Кажется, пришло время это обозначить.

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

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

Но на практике обучение и развитие — это не столько про личную мотивацию, но и про социальные отношения. Люди вкладывают силы потому, что считают сам процесс развития осмысленным и безопасным для себя. И одна из задач нас как лидеров (формальных или нет) — как раз придать процессу осмысленность и безопасность

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

Разбираться в этом мне будет помогать Ася Исакова — организационный психолог (магистр Work, Organizational & Personnel Psychology) и приглашённый лектор университета Pompeu Fabra (Барселона).

Почитать Асю можно в её канале: Это База | Компас конгруэнтности

Дата: 26 января 18-00 мск. Добавьте себе в календарь https://addcal.io/e/yd2ty2ewu9m6

Ссылки на стрим
Youtube
Zoom

Если у вас есть кейс, который хочется разобрать — пишите сюда или в личку (если хочется анонимности)

Сейчас разбираюсь в проекте на не совсем мне привычных Python/Django. Естественно использую агенты для изучения и модификации. Поменял код, поправил, потестил, залил в репу, создал ПР, мне накидали комментов — все как обычно.

Дальше я настроил в копайлоте github mcp, хотел по очереди получать правки, менять код и коммитить. Но промпт получился слишком общим. В итоге агент сам поправил весь код в соответсвии с комментами, запушил, прокомментил в пулл-реквесте через mcp. Ладно я сознательный — посмотрел коммиты, добил промптами пару вещей, которые явно не были проговорены в пулл-реквесте, дополнительно отревьювил код ллмкой и только после этого понес на повторное ревью.

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

Саша Поломодов запилил книгу сайт про Систем дизайн и все что около. Саша давно форсит эту тему — круто, что у него дошли руки все это скомпилировать.

https://system-design.space/

Друзья, уже через час ждем вас на стриме, выбирайте удобную платформу и усаживайтесь поудобнее

Вопросы, кейсы, комментарии пишите в этом треде или в личку, если нужна анонимность

Youtube
Zoom

Велкам! 🎉

Сегодня так много интересного!!!

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. Финальный тур ЛЧ 🙈

Альберто Брандолини с командой выкатили паттерны для проведения Event Storming

https://www.eventstorming.com/patterns/

Рекомендую ознакомится, но кажется главная проблема теперь как позвать агентов на такой воркшоп

Завидую джавистам в том что у них есть такие спикеры как Алексей Шипилёв (рассказывает всякое про сборку мусора) и Андрей Бреслав

Очень интересный подкаст про котлин и как его делали https://newsletter.pragmaticengineer.com/p/the-programming-language-after-kotlin

в свете использования LLM для разработки людя много обсуждают покупать или строить. Если смотреть с позиции DDD, то все однозначно: generic сабдомен покупаем, core саюдомен строим сами, supporting -- как получится.

Но LLM -- геймчейнджер, и теперь люди задаются вопросом, зачем нам платить за SaaS $n per months per user, если мы можем просто такой же саас навайбкодить за вечер (и пачку токенов)?

Для меня ответ по-прежнему прост: можете купить зрелое решение -- купите. Дорого? Попробуйте план попроще. Все равно не по карману? Посмотрите на опенсорс!

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

Когда все таки кодить/вайбкодить с нуля имеет смысл?

1. На рынке нет устоявшихся/готовых решений для вашей проблемы. В том числе из-за санкций или других ограничений.
2. У вас какие-то специфические требования (реально специфические, а не просто "мынетакиекаквсе"). Например, требования регулятора или стратегическое решение компании. Но и то я бы начал с обзора опенсорсных решений под подходящей лицензией.
3. Вам нужен какой-то небольшой набор фич от огромного и дорогого сааса. Опять же можно посмотреть на конкурентов.
4. Когда продукт может стать частью портфеля компании. Если сфера SaaS близка компании и есть желание реализовать свою экспертизу в продукте, то вполне хороший повод стартануть такое как внутренний продукт. Но будьте готовы, что будут не только прямые затраты на разработку, но и на косвенные на адаптацию.
5. Вы крупняк и платить даже большой команде разработки заметно дешевле.


Вы начали уже вайбкодить что-то своё вместо подписки?

Опять про ллм- разработку.

Сейчас на работе у меня сложилась идеальная ситуация

Есть достаточно большой неизвестный мне проект на плохо известном стеке (джанга)

Есть набор задач без горящих дедлайнов

Есть надежные процессы, которые не пропустят дичь на прод

Есть мое, как мне кажется, неплохое понимание прекрасного в разработке

И вот чувствую себя как на эмоциональных качелях: от восторга до полного разочарования и обратно.

Код он пишет и правда быстро, но с одной небольшой задачей я застрял уже на несколько итераций.

Вроде все просто: надо взять токен и в бекграунд таске сходить в другую систему.

Но оказалось:

Тот токен который есть нельзя использовать для этого обращения

Передавать нужный токен в celery таску несекурно

Кэш основной аппки и селери разделен — нельзя использовать просто тот же метод получения токена

При переходе на треды могут начаться проблемы с утечкой коннекшенов.

И вот с каждой итерацией решение усложняется и усложняется, хотя на старте казалось что там «пять минут работы программиста»

И пока что я не понимаю что делать с подобными задачами. Изначально они все выглядят одинаковыми по сложности