Размышление о backend‑архитектуре между двумя крайностями: академической чистотой и радикальным прагматизмом. На примере read/write path, CQRS, кэширования готовых ответов и собственного framework‑а на Go я показываю, как архитектурные шаблоны сталкиваются с production‑реальностью.
В статье описывается подход к разработке прикладных приложений, основанный на едином максимально подробном формате описания доменных сущностей и контрактов. Приводятся практические примеры использования такого описания. В том числе показано, как декларации могут привнести удобства low-code решений в обычные full-code программы.
Описанный подход работает независимо от используемого на проекте стека технологий и особенно полезен в гетерогенных системах. Поэтому я стараюсь приводить примеры из разных языков программирования и технологий: Java, Python, TypeScript, REST, GraphQL, protobuf.
Два часа ночи, у разработчика горит релиз, он подключает ваш API — и получает в ответ голое «invalid_request». Что не так, почему, что делать — ни слова. Сорок минут гаданий и злое письмо в поддержку.
Разбираем, как сделать опыт разработчика (DX) человеческим: как переписать ошибки по стандарту RFC 9457, но для живого человека; почему время до первого успешного вызова — главная метрика онбординга; и отчего предсказуемый, «скучный» API — это комплимент. С готовым шаблоном, который можно прикрутить к себе сегодня.
Большинство современных архитектурных подходов учат нас строить всё больше слоёв абстракции: контроллеры, сервисы, репозитории, адаптеры, транспортеры… Но что, если сложность системы растёт не из-за предметной области, а из-за самой архитектуры?
В этой статье я представляю FASA (Flat Adaptive Software ARchitecture) — спецификацию, которая предлагает радикально простой ответ: всего три сущности, строгие правила зависимостей и никаких промежуточных слоёв.
Вы узнаете, почему «плоский» граф компонентов может быть устойчивее многослойной архитектуры, как версионировать интерфейсы без боли, используя правило двойной поддержки (N-1) и где проходит граница между семантикой приложения и инфраструктурой — и почему это важно.
Спецификация языково-независима: примеры приведены для разных контекстов (Rust, сетевые протоколы, IPC), но правила применимы в любом стеке.
Долгоживущие системы почти никогда нельзя просто заменить целиком. Это слишком дорого и слишком рискованно: у них уже есть интеграции, пользовательские привычки, отчёты, ручные обходные процессы, внешние контракты и эксплуатационные ограничения.
Поэтому на практике такие системы переписывают по частям. Но для этого мало сохранить код или даже внешнее поведение. Нужно сохранить связь между целью системы, её ограничениями и конкретной реализацией. Эта связь должна переживать смену разработчика. Если она живёт только в головах, каждое серьёзное изменение снова начинается с археологии.
Из трёх мажоров, описанных в предыдущей статье, два не всплыли в тестах. Они всплыли в двух дизайн-ревью, которые тесты провести не могут.
Когда шаблонных интерфейсов продукту становится недостаточно, его команда начинает задумываться о внедрении конструктора страниц. Пользователи получают свободу кастомизации, а количество запросов на доработки существенно сокращается.
Но за этими очевидными преимуществами скрывается ряд технических сложностей. Вместе с гибкостью приходят конвертации, конфликты конфигураций, рост стоимости поддержки и потеря контроля над пользовательским интерфейсом.
В этой статье я от лица разработчика платформы событий Saby Meet расскажу о том, как мы внедряли механизм конструирования страниц, с какими ограничениями столкнулись и почему главным вызовом для нашей команды стала не реализация решений на конструкторе, а борьба с хаосом, который неизбежно пришёл в наши лендинги вместе с гибкостью.
Представьте, что вы работаете над кодом магазина, который живёт уже много лет. Бизнес доволен, продажи растут, но есть одна проблема — модуль обращения к весам превратился в чёрный ящик. Когда-то давно он работал прекрасно, но со временем разросся. Многопоточность, низкоуровневый код и бизнес-логика сплелись в один клубок, каждое изменение могло что-то сломать. И так дошло до того, что появились несколько фич, которые не реализовывались уже полгода... Стало ясно, что требуется не столько рефакторинг, сколько новая, удобная для работы абстракция.
Приветствую! Меня зовут Иван Матвеев, я разработчик в компании X5, и сегодня я расскажу, как мы начали рефакторить наши весы.
Во Flutter экран связан с жизненным циклом виджета: пользователь может вернуться назад, открыть другую вкладку или свернуть приложение, после чего состояние экрана уже будет уничтожено. При этом асинхронная операция может продолжать выполняться: сетевой запрос, обработка данных или отложенный callback не завершаются мгновенно.
Основная сложность заключается в том, что после ожидания состояние приложения может измениться: экран мог быть закрыт, пользователь мог ввести новый поисковый запрос, а активная вкладка — смениться. Если после этого без дополнительных проверок обновить состояние или выполнить действие с интерфейсом, приложение может показать устаревшие данные, вызвать лишнюю перерисовку или получить ошибку при обращении к уже неактуальному экрану.
В этой статье рассматриваются практические сценарии, которые часто встречаются в обычных Flutter-приложениях: загрузка данных, поиск, работа с подписками и обновление интерфейса после асинхронной операции.
Мы проверили фичу Dynamic Workflows на реальном проекте. Не ради хайпа или оценки "хорошая фича" / "плохая фича". Вопрос был чисто практический:
- усиливает ли Dynamic Workflows наш текущий стек;
- где это имеет смысл применять внутри нашего фреймворка;
- где это может быть полезно тем, у кого своего фреймворка нет;
- и где лучше не тратить на это лимиты, токены и время.
Три захода, шесть прогонов, четыре миллиона токенов. Демки обещали магию. Реальный проект дал швы, грабли и один по-настоящему страшный момент с ложным одобрением. Но из всего этого мы вытащили приёмы, которые сделали наш обычный процесс лучше. А workflow оставили для тех случаев, когда одного ревьюера действительно не хватает.
Принципы SOLID, DRY, KISS во фронтенде работают ровно так же, как в любой другой разработке. Но если открыть почти любой проект, всё равно натыкаешься на мешанину.
Причём дело обычно не в том, что код «грязный» — он как раз бывает типизирован и проходит linter. Дело в том, что эти принципы отвечают на вопрос «как написать», а не «зачем мы вообще это пишем». А без ответа на «зачем» чистый код превращается в красиво оформленную путаницу.
На примере такой вещи, как store попробуем ответить на вопрос: что вообще такое контракт, зачем же нужна типизация и действительно ли это помогает в разработке.
Привет, Хабр!
В этой статье я расскажу об эволюции моего проекта — GroupModerBot, бота для модерации Telegram‑групп. Я покажу, как проект прошел путь от первой версии «всё в одном файле» до продуманной архитектуры с ООП, in‑memory кэшированием, безопасным выполнением команд и нестандартными алгоритмами наказаний пользователей.
Всем привет! Меня зовут Миша, я разрабатываю платформу Яндекс Еды. В декабре я рассказывал, как Temporal без боли решает привычную проблему распределённой бизнес‑логики.
В продолжение темы я задумал написать такую статью, которую мне самому хотелось бы прочитать перед тем, как мы начали миграцию на Temporal. Всё изложенное проверено на практике: процессинг заказов Яндекс Еды уже почти год работает целиком на Temporal. Об общих принципах работы с Temporal я уже рассказал в предыдущей статье, а здесь я поделюсь полезными советами, выведенными из нашего опыта.
Некоторые части специфичны для разработки на Go, а другие вполне универсальны. Они организованы от общих к частным. Поделюсь практическими советами по архитектуре, тестированию, детерминизму и безопасному развитию Workflow. Покажу, как организованы миграции и эксплуатации в крупном продакшене.
В первой части я разбирал, почему spec-driven development начинает ошибаться, когда фича проходит через несколько микросервисов. Проблема не в том, что LLM плохо читает код или не умеет писать спеку. На уровне отдельных сервисов всё может выглядеть аккуратно: есть описание, план, реализация и тесты. Но правила, которые связывают сервисы между собой, часто не записаны в одном месте. Часть таких правил спрятана в реализации, часть известна только команде, а часть всплывает уже на ревью. Обычный Markdown не решает эту проблему: его легко написать неполным, сложно проверить автоматически и почти невозможно ревьюить как структурный контракт.
Отсюда родилась идея: нужен машиночитаемый контракт на каждый сервис, который фиксирует межсервисные правила, проверяется на коммите и даёт LLM структурный контекст вместо набора Markdown-файлов. Для этого я собрал open source плагин для Claude Code — archspec.
В этой части я покажу, как работает /archspec:init на одном сервисе из демо-проекта freelance-marketplace, разберу сгенерированные артефакты и объясню, как archspec поддерживает их в актуальном состоянии. Напомню, это Go-проект с 12 микросервисами для поиска фрилансеров. Вот схема сервисов, которую я использую на протяжении всего цикла:
Я строю Telegram-first SaaS в одиночку, а весь код за меня пишут ИИ-агенты Claude Code, и довольно быстро я уперся в неприятное: каждый новый агент приходит на работу с чистой памятью, не находит уже написанное, грепает по выдуманным именам и пишет свою реализацию заново - так за неделю в репозитории набегает +65К -1.5К строк, а устоявшиеся паттерны тихо расходятся.
Это третья статья серии про разработку руками агентов, и в ней - честный разбор того, как я строил для своей команды из амнезиков слой памяти о коде. Почему клоны от ИИ это в основном Type-4, которые токенные детекторы попросту не видят; почему векторная база здесь неправильный основной фикс; как граф концептов на локальной модели лег почти один-в-один на когнитивную науку о человеческой памяти (Тульвинг, Вегнер, Спэрроу); и как на одном страшном отрицательном результате я чуть не усложнил себе архитектуру ради проблемы, которая решалась переписыванием одного абзаца. С тупиками, цифрами и слепым A/B-тестом, без срезанных углов.
Выпадающий список — это ui-компонент, без которого редко обходится сайт. В этой статье я расскажу про то, как принял решение отказаться от enum для рендеринга выпадающих списков и перешел к конфигу-константе, и почему результат мне понравился.
⚡ Архитектура монорепозитория для параллельного исполнения торговых стратегий
Статья описывает архитектуру эмулятора биржи. Эмулятор ускоряет время в 6300x раз и запускает такую же торговую стратегию как в prod без изменений. В статье описаны практики структурирования кодовой базы для командной работы
B-Tree O(log n) , memcache lookupO(1), монорепозиторий, SRP, линейное расширение кодовой базы при модернизации
Привет, Хабр! Меня зовут Кирилл, я партнер брендингового агентства «Бунов+Устинов». Пока индустрия спорит, заменит ли ИИ кожаных мешков, мы с архитектором проекта Сергеем Либединским решили проверить это на самой «душной», долгой и дорогой части нейминга - юридическом скрининге товарных знаков.
Это история о том, как превратить галлюцинирующую LLM в строгий экспертный инструмент, пережить «догфудинг» собственной нейронкой и получить награду «ОСНОВА-2026» за автоматизацию процессов в брендинге.
Устройства дополненной реальности — это устройства, которые обеспечивают интерактивное взаимодействие с реальным миром, интегрируя цифровой визуальный контент и аудио в окружающую среду. К устройствам дополненной реальности относятся проекционные дисплеи, голографические дисплеи, смарт-очки и другие.
Основными типами устройств дополненной реальности являются дисплеи, надеваемые на голову (head-mounted display, HMD), и проекционные дисплеи (head-up display, HUD). Устройства дополненной реальности используются в самых разных отраслях, в том числе в потребительской, коммерческой, корпоративной, здравоохранении, аэрокосмической и оборонной промышленности, энергетике и автомобилестроении. Популярные англоязычные аббревиатуры (VR, AR, MR) — это соответственно виртуальная, дополненная, смешанная реальность.
Посмотрим, что происходит в этой сфере в России и мире с точки зрения патентов.
На текущем месте работы я иногда вижу запросы на систему распределения затрат по определенным правилам, которые должны гибко изменяться без необходимости пересборки всего приложения.
Исходя из текстов запросов, создается впечатление, что многие считают эту задачу сложной и требующей создания специфических, заточенных именно под данную задачу решений.
Однако, исходя из того, что я знаю про Apache Spark, с его помощью и используя расширение по работе с графами, это не выглядит сложной задачей.
Я решил это проверить.
В данной статье будет описана задача и выбранные технологии.
Во второй части будет описана база данных для хранения правил и результатов.
В третьей части будет создано решение на базе Apache Spark и его функций по работе с графами.
Бонусом получится сравнить скорость выборки результирующих данных из Postgres с помощью рекурсивных запросов и запросов к Apache Spark с помощью GraphFrame.
