Здравствуй, разработчик!

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

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

🔮 Базовые заклинания

Роберт Мартин — «Чистая архитектура»
Чтобы понять, что архитектура это не про фреймворки, а про границы, ответственность и направление зависимостей. Даёт язык для обсуждения архитектуры в команде.

Саймон Браун — «Software Architecture for Developers»
Коротко и по делу: как думать об архитектуре, не утонув в схемах.

Сэм Ньюман — «Building Microservices»
Хорошая вводная в распределённые системы: что в них реально усложняется и почему микросервисы — это выбор, а не апгрейд.

Дейв Фарли — «Современная программная инженерия. ПО в эпоху аджайла и непрерывного развёртывания»
Основная идея книги в том, что программирование — это не магия, а инженерная дисциплина, основанная на научном методе. Понятия «хорошей» архитектуры и качества Дейв сводит к двум базовым вещам: управлению сложностью и поддержанию скорости изменений.
🎬Кстати, у Дейва есть отличный канал на Ютубе.

🪄Сложные чары

Сюй Алекс — «System Design. Подготовка к сложному интервью»
Эта книга не только про интервью. Она учит структурировать рассуждения, задавать правильные вопросы и объяснять решения так, чтобы вас понимали.

Крис Ричардсон — «Микросервисы»
Про реальную стоимость микросервисов, компромиссы и сложности, о которых обычно забывают на старте.

Нил Форд, Марк Ричардс, Прамод Садаладж и Жамак Дехгани — «Software Architecture: The Hard Parts»
Про самые неудобные вопросы архитектуры: где провести границы, когда разделять систему и какие компромиссы действительно важны.

🧙‍♂️ Высшее искусство

Мартин Фаулер — «Patterns of Enterprise Application Architecture»
Многие паттерны из книги вы уже встречали в проде, просто не знали, как они называются. Помогает систематизировать опыт и лучше понимать чужие решения.

Нил Форд, Ребекка Парсонс, Патрик Куа, Прамод Садаладж — «Эволюционная архитектура»
От ребят из Thoughtworks. Главная идея: архитектура должна жить и дышать, а ключ к этому fitness functions, которые автоматически проверяют, не ушли ли вы в отрыв от заданных характеристик системы. По сути, авторы предлагают заменить скучные code review и архитектурные комитеты железобетонной автоматизацией. Местами книга напоминает экскурсию по инженерной кухне Thoughtworks с разбором реальных кейсов, что реально полезно.

Ли Атчисон — «Architecting for Scale»
Про мышление архитектора: как думать о росте, изменениях и последствиях решений ещё до того, как появляются проблемы.

☠️ Запретный том

Лен Басс, Пол Клементс, Рик Казман — «Software Architecture in Practice»
Сложная, плотная, не развлекательная, но именно она чаще всего оказывается ответом на вопрос «а почему мы вообще так сделали?».

А какие книги или материалы помогли вам больше всего? Делитесь своими рекомендациями в комментариях!

🌍 Kafka и искусство отпускать прошлое

Мы часто рассчитываем, что Kafka «как-нибудь сама разберётся» с хранением данных, а потом внезапно обнаруживаем, что она разобралась, но не совсем так, как мы планировали.

В этом лонгриде Павел Иванов, администратор баз данных, разбирает, как Kafka на самом деле решает, что хранить, что сжимать, а что удалять, и почему политики очистки часто ведут себя не так, как мы ожидаем, когда просто ставим retention и идём дальше писать код.

🏃 Зачем это нужно?
Без понимания очистки люди начинают: хранить лишнее в базе, угрожать жизни брокеров или делать сложную логику на стороне consumer.

🏃 Читайте и наводите порядок в своих данных

👉 Разделяй и властвуй. Но аккуратно

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

Во второй части цикла Фёдор Засечкин, руководитель группы разработки операционной платформы, поделился, что происходит после решения «выносим в сервис»: как не собрать распределённый монолит 2.0, зачем пересматривать ответственность команд и почему иногда сложнее договориться, чем переписать код.

🏃 Часть 2 — уже на Хабре.

Весна, солнце и новые вакансии

С потеплением хочется больше движения и перемен — кажется, весна для этого идеальное время. Поэтому делимся свежим дайджестом вакансий:

🟢 Technical manager / Data Scientist (Middle)

Ищем Data Scientist’а, который поможет нам развивать динамическое ценообразование в Купере. Нужно будет разрабатывать и запускать ML-модели, исследовать данные, находить новые гипотезы и проверять их вместе с командой. Важно уметь быстро прототипировать решения, работать с Python и SQL, делать EDA и понимать, как ML влияет на бизнес-метрики продукта.

🟢 Менеджер продукта в команду Мерчантов (Middle)

В команду Мерчантов ищем продуктового менеджера, которому интересно развивать механики каталога — скидки, бейджи, категории, отзывы и другие элементы витрины. Нужно будет искать точки роста, запускать новые фичи вместе с клиентским продуктом и технической командой, а также вести задачи от идеи до релиза и дальнейшего развития. Важен опыт продуктовой работы, data-driven подход и умение вести кросс-командные фичи.

🟢 Менеджер продукта в команду Мотивации (Middle)

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

🟢 UX-исследователь в команду Операции (Middle)

В нашу команду Операций ищем UX-исследователя, который поможет глубже понимать пользователей и приносить продукту полезные инсайты. Нужно будет проводить качественные и количественные исследования, общаться с респондентами, продумывать дизайн исследований и делиться результатами со стейкхолдерами. Важно уметь вовлекать команду в исследования и помогать применять их результаты в продукте.

🟢 MLOps-инженер (Senior)

Ищем инженера, который будет развивать ML-платформу Купера: строить систему автоматизации жизненного цикла моделей, внедрять новые технологии в ML-стек и участвовать в проектировании ML-архитектуры. Важно иметь опыт разработки ML-пайплайнов, понимать CI/CD и инфраструктуру данных, работать с Python, SQL, Kafka, Docker и Kubernetes. Будет плюсом опыт с инструментами MLOps-экосистемы и развёртыванием LLM-решений.

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

😏 Соскучились по офлайну? Встречаемся на DevOpsConf!

2 и 3 апреля приходите послушать доклады наших экспертов и пообщаться после выступлений:

🟢Автоматизируй это немедленно! Инциденты, когда на кону большие деньги. Дарья Попова, руководитель группы мониторинга и Алексей Глотов, руководитель группы разработки.

🟢SLO as a code — нельзя верить людям. Вячеслав Литкович, руководитель группы инженеров ИТ-инфраструктуры.

🟢Воркшоп «Observability: system design». Максим Бурцев, руководитель отдела мониторинга, и Кирилл Гриднев, инженер разработки автоматизаций внутренних процессов, будут консультировать команды и разбирать их решения в составе жюри.

Ставьте 🔥, если идёте на конференцию или будете смотреть её онлайн!

👉Доставка полезных материалов для Go-разработчиков!

В Купер.тех мы в основном пишем на Go, и многие инженерные решения так или иначе упираются в производительность, архитектуру и умение работать с нагрузкой. Дмитрий Петухов, инженер команды прайсинга и мотивации курьеров, поделился материалами, которые помогают ему с этим в работе:

🌍Язык, перфоманс и инженерные компромиссы

Efficient Go — Бартоломей Платка (соавтор Thanos и контрибьютор Prometheus)

Если возникает задача снизить потребление ресурсов и при этом оставаться готовыми к высоким нагрузкам, она может казаться противоречивой. Благодаря прагматичным подходам из книги становится понятно, что это вполне достижимо. Автор поможет сформировать правильное мышление в подходах к оптимизации, залезет под капот Go, расскажет много интересного о процессоре и использовании памяти, а также разберет, как эффективнее всего использовать pprof, и поделится, так ли хорош sync.Pool.

🌍Архитектура

Чистая архитектура Golang проекта — Олег Козырев
📱смотреть

В гайде автор начинает с простой задачи, реализует её в main-файле, и по мере появления новых требований архитектура сервиса постепенно усложняется. Рассматриваются в том числе такие концепции, как Value Objects, Entity, Aggregate, Anti-Corruption Layer.
Осторожно: видео на 3 часа, но, как известно, вечно можно смотреть на огонь, воду и на то, как новые бизнес-требования встраиваются в сервис с неподготовленной к ним архитектурой. Считаю этот ролик отличным стартом для знакомства с DDD.

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

Learning Domain-Driven Design — Влад Хононов

Доступная книга по DDD. Плавный вход в тему: объясняет базовые концепции и, что важно, помогает понять, когда DDD действительно нужен, а когда это избыточно. По сравнению с Эвансом более сжато и четко структурировано. Если не осилили DDD от Эванса, советую начать с нее.

Domain-Driven Design — Эрик Эванс

Классика, которая не стареет. Если «Learning Domain-Driven Design» от Хононова — это быстрый вход в мир DDD с фокусом на тактические паттерны (сущности, агрегаты, value objects), то «синяя книга» Эванса — про стратегию и мышление. Автор подробно объясняет фундаментальные принципы DDD, подкрепляя их своим опытом применения.

Implementing Domain-Driven Design — Вон Вернон

Практическое продолжение «синей книги». Фокус на практике применения DDD. Автор детально разбирает агрегаты (их размер, границы, правила проектирования), репозитории, доменные сервисы и, что особенно ценно, показывает, как работать с ограниченными контекстами в реальных системах.
Что особенно удобно, книга подходит как справочник, его можно открывать отдельные главы под конкретные задачи (например, агрегаты).

Go: идиомы и паттерны проектирования — Джон Боднер

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

Будем рады, если эти материалы окажутся полезными. А какие книги или доклады по Go и архитектуре помогли именно тебе? Пиши в комментариях!