Backend Portal | Программирование

DDD — это концепция, которую я часто вижу недооценённой, хотя по моему опыту она оказалась реально полезной. Часто, когда говорят про DDD, сразу думают про bounded contexts, aggregates, сущности, value objects. И это нормально. Но я считаю, что сердце DDD не в архитектуре, а в языке. Единый (Ubiquitous) язык — это не красивый словарик и не набор умных терминов. Это семантическое соглашение между бизнесом и технологиями. Живой контракт, который определяет, как мы думаем, как называем вещи и как решаем проблемы. Что такое Единый язык на самом деле Это набор слов, понятий и правил, которые вся команда использует для описания домена. Не в теории, не на стикерах, а в коде, в разговорах и в документации. Например: Если бизнес говорит «подписка», а в коде у тебя «membership». Если бизнес говорит «фактическая отмена», а в коде используется «softDelete». Если бизнес различает «клиента» и «потребителя», а в модели у тебя везде просто «User». Значит, у тебя нет Единого языка. У тебя есть ментальные переводы, путаница для всех, кто не технарь, куча неоднозначностей, и эти проблемы коммуникации рано или поздно превращаются в баги. Как ни крути, софт — это отражение бизнеса. Если язык в коде не совпадает с тем, как мыслит бизнес, ты увеличиваешь риск построить систему, которая не отражает реальность. А когда реальность не совпадает с кодом, ты получаешь продукт, который может не соответствовать исходным ожиданиям. Единый язык как раз и пытается убрать этот разрыв. Он делает так, чтобы домен существовал и в голове у бизнес-эксперта, и в твоём редакторе кода. Как это выглядит в реальном проекте Например, если бизнес говорит: «Заказ может перейти в статус “Одобрен”, только если платёж подтверждён». Твоя модель должна отражать это напрямую:

    
        order.approve(paymentConfirmation);{}
    

А не вот так:

    
        order.validate();
order.setStatus(3);{}
    

Единый язык можно проверять так: Код выражает смысл? Или он выражает только реализацию? Почему его так сложно внедрять Честно, точно сказать сложно. Из того, что я видел, — это сильно бьёт по многим разработчикам. Особенно потому, что нас заставляют менять язык, который мы годами видели, слышали, читали и использовали. А такой сдвиг даётся нелегко. И ещё важный момент Единый язык — это не религия. Его не обязательно применять в каждом проекте и в каждой команде. Есть домены настолько хаотичные, широкие или постоянно меняющиеся, что построение общего языка обходится дороже, чем приносит пользы. И это нормально. DDD — это не догма, это инструмент. Используй его, когда он помогает прояснить модель, снизить неоднозначность и принимать более точные решения. Не используй, когда поддержка этого языка стоит дороже, чем выгода. Важно не «делать DDD», а моделировать софт так, чтобы команда могла лучше думать и лучше строить. Если Единый язык тебя к этому приближает, значит, он занял своё место не зря. 👉 @BackendPortal

Этот трюк с GitHub PR надо знать Просто добавь “0” перед словом “github” в URL любого Pull Request, и у тебя откроется полноценный PR-вьювер, который подсвечивает каждую строку diff’а цветом в зависимости от того, сколько внимания от человека она, скорее всего, требует. Он ищет не только баги. Он подсвечивает всё, что заслуживает второго взгляда: захардкоженные секреты, странные крипторежимы, подозрительную логику или грязный код. Очень полезный способ быстрее проводить code review и находить то, что обычно легко пропустить. 👉 @BackendPortal

Когда между идеей и продом — преград нет! В VK любят решать сложные и масштабные задачи, а ещё — быстро реализовывать идеи. Компания рассказала, каких принципов придерживается команда в работе и какими результатами гордится. Переходите по ссылке, там много интересного!

Раньше у GitHub была монолитная база данных, которая держала 950 000 транзакций в секунду 🤯 Но по мере роста компании эта база превратилась в... сами понимаете что. Логичное решение = развалить монолит на несколько меньших баз. На деле все оказалось гораздо сложнее, чем они думали. Я как раз нашёл видео, где разбирают весь их процесс: какие шаги они предпринимали, как сделали миграцию без даунтайма и при этом ничего не сломали в существующем функционале. После просмотра ты поймешь, как в реальных проектах мигрируют базы без простоя, как подходить к таким сложным задачам по шагам, и получишь живой пример того, с какими проблемами сталкиваются при масштабировании баз данных и как их решают. 👉 @BackendPortal

Когда приложению нужно узнать о чем-то важном, например что пользователь оплатил подписку, у тебя есть два варианта: 1. приложение дергает API раз в пять минут, проверяя, был ли новый платеж; 2. платежная система сама шлет тебе уведомление в момент события. Первый вариант — это polling: ты спрашиваешь, даже если ничего не произошло. Работает, но медленно и плохо масштабируется. Второй вариант — webhook: HTTP-коллбек, который срабатывает, когда произошло событие. Вместо того чтобы опрашивать систему, она сама присылает нужные данные. Как выглядит поток, если ты используешь вебхук: 1. настраиваешь публичный эндпоинт; 2. твой сервер принимает POST с данными платежа; 3. проверяешь подпись (секретный ключ); 4. выполняешь свою бизнес-логику (платеж подтвержден, подписка активна и так далее). Типичные проблемы: - платеж может прийти дважды, поэтому сохраняют обработанные ID (идемпотентность); - события могут прийти не по порядку, так что на хронологию лучше не рассчитывать; - запрос может отправить кто угодно, поэтому обязательна проверка подписи. Вебхуки важны потому, что избавляют приложение от постоянного опроса сторонней системы. Сегодня их используют везде: платежи, подписки, деплои, интеграции, автоматизации и вообще любые сценарии, где другой сервис узнает о событии раньше тебя. 👉 @BackendPortal

Уроки по ИБ, белый хакинг, вирусы, социальная инженерия, безопасность ИБ Книга — Более 1660 русскоязычных книг по ИБ и Социальной Инженерии можно найти на канале. no system is safe // cybersec — один из древнейших ресурсов по информационной безопасности в рунете. Книги, курсы, полезные тулсы, уроки по Linux, новости клирнета и даркнета. Python и 1000 программ — уроки по Python. Python мы будем использовать для создания хакерского софта. Этичный Хакер — один из крупнейших ресурсов по информационной безопасности в СНГ. Бэкап — канал с исходниками популярных проектов. Здесь вы найдёте исходные коды нейросетей, ботов, сайтов и других интересных проектов, которые дадут дополнительные знания Весь материал на каналах в общем доступе. Ничего лишнего.

Большинство людей используют grep чтобы искать по файлам. Я использую его чтобы выживать в продовых пожарах в 3 ночи. grep "error" logfile.txt → Ищет "error" в файле. grep -i "error" logfile.txt → Ищет без учета регистра. grep -r "TODO" /project/ → Рекурсивный поиск по директориям. grep -n "function" script.py → Показывает номер строки вместе с результатами. grep -v "debug" logfile.txt → Показывает всё, кроме строк с "debug". grep -c "warning" logfile.txt → Считает количество совпадений. grep -w "cat" animals.txt → Совпадение только по целым словам. grep -C 3 "exception" logfile.txt → Показывает 3 строки до и после совпадения. grep "import" *.py → Ищет сразу по нескольким файлам. grep -E "error|warning|critical" logfile → Ищет по нескольким шаблонам сразу. Тот самый продовый пожар в 3 ночи Приложение упало. Пользователи бесятся. Телефон разрывается. grep -rni "exception" /var/log/ | grep "2025-12-02" Это находит все исключения в логах за сегодня. С номерами строк. По всем файлам. Тысячи строк сужаются до причины падения за секунды. Почему это важно Твой IDE не работает на удалённых серверах. Не тянет гигабайтные логи. И точно не помогает в 3 ночи, когда прод лег. А grep помогает. Разница между джуном и сеньором? Умение пользоваться терминалом, когда это реально нужно. 👉 @BackendPortal

Тебя спрашивают на бэкенд-собесе. Вопрос:

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

Как к этому подойти: Начни с базовых требований: • централизованно определять и хранить расписания • несколько scheduler-нод, но в конкретный момент только одна должна триггерить задачу • задачи должны выполняться ровно один раз, даже если ноды рестартуют или падают • поддержка ретраев, backoff и идемпотентных обработчиков • видимость last-run и next-run Архитектура системы: • Control Plane: UI/API для создания cron-задач • кластер scheduler-ов • распределенный локинг (Redis, Zookeeper, Etcd, DynamoDB) • пул воркеров, который выполняет задачи • хранилище результатов и метаданных Гарантия, что задачу триггерит только одна нода: • на каждую задачу используется отдельный распределенный лок • нода, которая захватывает лок, и запускает выполнение • у лока есть TTL, чтобы не виснуть навечно • если нода умерла, другая подберет задачу на следующем тике Как работает планирование: • все scheduler-ноды подгружают cron-описания • каждую секунду каждая нода проверяет, что надо запускать • если задача должна стартовать, нода пробует взять лок • победитель отправляет задачу в пул воркеров Ретраи и ошибки: • у каждой задачи свои правила ретраев (число попыток и backoff) • при ошибке создается событие retry • ретраи тоже проходят через тот же механизм локов • воркер должен быть идемпотентным, чтобы переживать редкие дубликаты Масштабирование воркеров: • воркеры должны быть stateless и масштабироваться горизонтально • задачи — это сообщения с job ID и payload • используется очередь/брокер (Kafka, SQS, RabbitMQ) • планирование отделено от выполнения Консистентность и надежность: • cron-определения хранятся в консистентной базе • scheduler-ноды держат копии в памяти и периодически обновляют • сохраняется история запусков (start, end, статус, ошибка) • можно включить catch-up для пропущенных запусков Обсервабилити: • метрики next_run_at, last_run_at, длительность, успех/ошибка • Prometheus-метрики и трассировка медленных задач • алерты на зависшие задачи и повторные фейлы • UI с инфой, какая нода выполняла какой запуск Как ответить на собесе:

Я бы построил распределенный cron с централизованным управлением расписаниями, несколькими scheduler-нодами и распределенным локом, чтобы задача триггерилась ровно один раз. Выполнение вынесено в пул воркеров, каждый запуск логируется, ретраи координируются через очередь, и система остаётся консистентной даже при падении нод.

👉 @BackendPortal