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

Рассмотрим модель данных application model, которая потребуется в дальнейшем изложении и которая используется в паттерне CQRS.

Реализация архитектурного паттерна CQRS, используемого в приложении для функционала application logic, представляет собой набор классов наследников базовых классов QueryHandler / CommandHandler и набор классов данных, которые являются наследниками базовых классов Query / Command. Классы наследники Query / Command представляют собой модель данных application logic. Такую модель данных логично назвать application model.

Используя application model и другие известные модели данных слоёв приложения можно построить полную схему моделей данных многослойной архитектуры приложения.

Apache JMeter — не просто инструмент. В этой статье разберем, как получать от него реальную пользу. Вы узнаете, почему 80% отчётов о нагрузке бесполезны, как настроить распределённый тест и анализировать не среднее значение, а процентили. Полный гайд от первого HTTPS-скрипта до информативного HTML-отчёта и Best Practices.

Продолжаем серию «Kotlin для новичков». Сегодня разбираем фундамент, без которого не обходится ни одно приложение: строки и коллекции. Как правильно резать подстроки, форматировать JSON, чем List отличается от MutableList и зачем enum в Kotlin круче, чем в Java. Заглядывайте, будет полезно!

Представьте: сервис А звонит сервису Б, а тот зависает. Сервис А ждёт, занимает потоки, не освобождает ресурсы. Потом к нему приходит другой сервис — и тоже встаёт в очередь. Так один сбой разрастается по всей системе, как снежный ком. Этот эффект называется каскадным отказом.

Паттерн Circuit Breaker (предохранитель) решает эту проблему. В статье разбираем его на примере ассистента HR с зонтиком, показываем, как настроить Resilience4j, и делимся, какие ошибки стоит (а какие не стоит) учитывать в статистике.

 Описание

Паттерн Circuit Breaker (предохранитель) занимает важное место среди паттернов архитектуры приложений, особенно в микросервисных системах.

В чем его суть. Представим сервис А, который обращается к сервису Б. Сервис Б по каким-то причинам начинает плохо себя вести: долго отвечать на запросы или отвечать ошибкой — например, потерял соединение с базой данных. Тогда начинает «страдать» сервис А: он вынужден долго ждать на каждом запросе, занимая ресурсы — свободные потоки, соединения с БД, удерживая транзакции открытыми.

Проблема распространяется и умножается на всю систему. У сервиса А занимается всё больше потоков, которые ничего не делают, а просто ждут. Если будут заняты все потоки, сервис А станет полностью неработоспособен. Так проблема разрастается по цепочке — этот эффект называется каскадным отказом (cascading failure).

Чтобы решить проблему, сервис А должен иметь защитный механизм, который определяет, что сервис Б сейчас в аварийном состоянии, и временно не обращаться к нему. Этот механизм и называется Circuit Breaker (предохранитель).
 

Один экран в приложении, а на бэкенде несколько REST-вызовов, куча эндпоинтов и ответы, где 90% полей не используются. Теряем в скорости, усложняется фронтенд и приходится версионировать контракт, когда меняется формат данных.

GraphQL предлагает другой подход: один API-эндпоинт и запрос, в котором клиент сам указывает, какие поля ему нужны. Это снижает overfetching, уменьшает количество сетевых затрат и упрощает договоренности между фронтом и бэком за счет схемы как явного контракта и живой документации.

В новом переводе от команды Spring АйО разберем, где GraphQL реально помогает: как уйти от разрастания эндпоинтов, как держать контракт синхронизированным и что делать с типичными проблемами производительности и наблюдаемости, когда данные собираются из разных источников.

«Talk is cheap. Show me the code.»

Недавно мне в руки попала книга «Искусство неизменяемой архитектуры: теория и практика управления данными в распределенных системах». В ней описаны довольно радикальные, но логичные подходы к проектированию: полный отказ от UPDATE и DELETE в пользу INSERT, идентификация сущностей через хеш-суммы и построение распределенных систем без боли.

Чтобы не быть голословным и проверить, работают ли эти концепции в реальном коде, а не только в теории, я написал небольшой тестовый проект. Это не продакшен-решение, а скорее полигон для проверки идей.

В этой статье разберем, как выглядит REST-сервис на Kotlin + Spring Boot, живущий по законам неизменяемости, и к каким результатам это привело.

Это текстовая версия доклада с Java Rock Star Meetup, с которым выступал Александр Ланцов — ведущий разработчик Мир Plat.Form. Если вы больше любите смотреть видео, то смотрите запись доклада на YouTube или VK Видео.

Всем привет! Меня зовут Евгений Оселедец, я ведущий разработчик в компании Axenix. В этой статье расскажу, как мы упаковали React и Java в единое автономное desktop-приложение с помощью Electron для Windows, Linux и macOS — без Docker, без предустановленной Java у пользователя и без необходимости интернет-соединения. Расскажу, с какими техническими вызовами мы столкнулись и какие решения сработали на практике.

Привет, Хабр! Я Юрий Дергач, я возглавляю ЦК DevOps и релизного управления в РСХБ. Мы с командой развиваем инфраструктуру и автоматизируем разработку продуктов компании. При внедрении наших проектов группы «Экосистема Свое», основанных на стеке Java Spring, в Kubernetes, возникли вопросы, связанные с различными методами балансировки нагрузки между микросервисами.

В этой статье мы обсудим два основных подхода к балансировке нагрузки между Backend-компонентами приложений на стеке Java Spring Cloud в Kubernetes. Мы также рассмотрим преимущества и недостатки каждого метода.

Вы слышали о Kafka, MQTT, S3, Iceberg, Trino, PostgreSQL, Redis и Flink? А насколько хорошо вы знаете эти технологии? По каждой из них написаны огромные книги («Kafka: The Definitive Guide», около 800 страниц), и каждый день выходят новые публикации про тонкости.

Эта статья про другое.

Вместо внутренностей движков и законов распределённых систем посмотрим на эти технологии как на кубики LEGO: какую роль каждая из них играет в архитектуре и как они стыкуются друг с другом. Это будет практический туториал: начнём с минимальной конфигурации и постепенно соберём сложную систему. Статью можно просто читать как обзор архитектуры, а можно запускать каждую конфигурацию и изучать её в деталях. Для этого достаточно Git, Git LFS и Docker Compose. Всё запускается в контейнерах. Даже примеры на Java собираются через Docker multi-stage build.

Привет Хабр! Меня зовут Артур Валиев, и я разработчик небольшого мобильного приложения с названием «Echo Layer».

Меня давно не отпускала одна мысль: почти все разговоры о приватной переписке в какой‑то момент упираются не в шифрование, не в криптографию, не в архитектуру, а в банальную человеческую инерцию. Можно сколько угодно строить красивую систему, можно делать open source, end‑to‑end encryption, писать про zero knowledge и отсутствие серверных логов, но потом ты возвращаешься в реальную жизнь и видишь, что люди всё равно сидят там, где им удобно. В Telegram, в WhatsApp, в VK, сейчас уже и MAX, в корпоративных чатах, в почте, в комментариях, где угодно. И если для приватности нужно сначала всех пересадить в новое приложение, то задача почти обречена.

Именно в этот момент у меня и сместился фокус. Я перестал думать о мессенджере как о конечном продукте. Мне стало интереснее другое: а можно ли не строить новый канал связи, а встроить приватный слой поверх уже существующих каналов? Не просить человека менять привычки, не ломать его сценарий общения, не заставлять его уговаривать собеседника «перейти вот сюда», а аккуратно встать между пользователем и текстом. Потому что, если честно, в большинстве случаев мессенджер — это просто оболочка. Внутри всё равно есть текст, который пользователь написал, и текст, который приложение потом отправило. Значит, если контролировать текст до отправки, можно контролировать довольно много.

Так Echo Layer и появился. Не как «новый безопасный чат», а как попытка превратить сам ввод текста в место, где может жить приватность.

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

Эта статья для тех, кто делает первые шаги в распараллеливании тестов на Java. Будет полезна как автотестерам, так и начинающим разработчикам.

Будем анализировать выводы полученные в ходе эксперимента, а не голую теорию из документации. После прочтения сможете повторить все самостоятельно как на готовом примере из статьи, так и на своих проектах.

Всем привет! Меня зовут Михаил, я главный эксперт в ОТП Банке.

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

Разберем всё по шагам, с замерами производительности. Поехали!

Playwright или Selenium на Java — что выбрать для автотестов в 2026 году? Разбираю историю инструментов, различия в локаторах, ожиданиях, стабильности, стоимости поддержки и объясняю, в каких сценариях каждый из них лучше.

Привет, Хабр! Меня зовут Даша Александрова, я Java‑разработчик. Хочу поделиться опытом миграции данных из Oracle в PostgreSQL без простоя сервисов.

Причина миграции — импортозамещение.

Теперь немного про сам проект. В его основе — микросервисная архитектура на Java 11/17 и Spring Boot 2/3. В качестве основной базы данных использовалась Oracle с несколькими схемами. В коде сочетаются нативные SQL‑запросы и Hibernate, вся бизнес‑логика живет на уровне приложения — без процедур, триггеров и другой логики в базе. Идентификаторы генерируются через sequence. Проект активно развивается, регулярно выпускаются релизы. Система ориентирована на клиентские приложения — мобильное и веб, при этом нагрузка остается умеренной и не относится к highload‑сценариям.

Ключевое нефункциональное требование — выполнить миграцию без простоя системы и без заметного влияния на пользователей.

Может возникнуть логичный вопрос: если такие миграции уже делались не раз, почему просто не взять готовое решение? На практике универсального подхода не существует.

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

Рефакторинг должен быть скучный и надежный. Надо держаться от искушения обновить библиотеку, починить баг, улучшить стиль. Под катом разбор почему именно такой путь сможет вытянуть тяжелый legacy рефакторинг, а шаг вправо и влево ведет к откату релиза.

В этой статье я расскажу историю одного «многосерийного» исследования, в котором было всё:

Реверс-инжиниринг APK и поиск ключей AES (спойлер: они лежат прямо в коде).

Бюрократический пинг-понг между Минцифры, Роскомнадзором и разработчиками, которые вместо реальных исправлений лепят костыли.

И финальный аккорд: как с помощью Arch Linux, Waydroid и одной правки в XML-конфиге превратить обычный аккаунт ученика в полноценный профиль учителя с доступом к журналам, оценкам и кнопкам редактирования всей школы.

Добро пожаловать под капот системы, где сервер верит клиенту на слово.

Всем привет! Меня зовут Александр, и сегодня я расскажу о результатах перевода учебного проекта со Spring WebFlux и Netty на Spring MVC и Tomcat с виртуальными потоками и проверки обоих вариантов под нагрузкой в 2000rps. В качестве подопытного будет выступать система микросервисов, разработанная в рамках курса CloudJava.

Привет, Хабр!

Почему инженеры хотят делать новое, а неделя уходит на сопровождение, алерты и переключение контекстов? Поводом для этой статьи стали два материала, которые неожиданно сошлись в одной точке: доклад Романа Елизарова про опыт разработчика и отчет Chainguard Engineering Reality Report 2026. Мы сопоставили взгляд сильного практика и международные данные, чтобы понять, куда на самом деле утекает внимание инженерных команд и почему DX сегодня — это уже не про удобство, а про экономику внимания.

GitHub, GitLab или Bitbucket — куда податься начинающему разработчику в 2026? Казалось бы, какая разница — Git везде одинаковый. Но когда дело доходит до первого пет-проекта, портфолио или стартапа на троих, выбор платформы решает всё: от скорости сборки до шансов быть замеченным рекрутером.

В этой статье — сравнение лимитов, цен и скрытых фич. Разберём реальные сценарии, таблицу с актуальными данными на апрель 2026.

Что делать, если синхронные REST-вызовы превращают ваши микросервисы в карточный домик? Пора вспомнить проверенные временем паттерны обмена сообщениями. В этой статье разбираем архитектуру Pipes and Filters, Content-Based Router и Idempotent Receiver — те самые кирпичики, на которых держатся надёжные системы. Схемы, best practices для проектирования устойчивых интеграций для Enterprise-разработки.

Вот уже 18 лет статический анализатор кода PVS-Studio находится на рынке. За это время он обзавёлся поддержкой языков C, C++, C# и Java. Разумеется, останавливаться на этих языках мы не планируем, и в этой статье расскажем про разработку нового JavaScript/TypeScript анализатора, который выйдет уже совсем скоро.

Проблема фундаментальная: system prompt — это инструкция, которую LLM старается выполнить, но не обязан. Модель может её переинтерпретировать, «забыть» при длинном контексте или просто обойти через специальные конструкции. Guardrails — это другой уровень: они работают на уровне кода, до и после вызова LLM, и модель физически не может их обойти.

История о том, как я выпустил популярный ORM в 2012 году… потом похоронил его… потом осознал, что база данных должна быть единственным источником правды. И к чему это привело.

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

А также:
▫️ Почему фраза «создайте мне систему» — это красный флаг.
▫️ Как постепенное уточнение спасает от «аналитического паралича» и переписывания кода.
▫️ User Story vs Use Case: в чём настоящая разница и что выбрать.
▫️ Схемы итеративного процесса и ролей в Agile-проекте.

Девятый выпуск еженедельных IT-новостей от OpenIDE.

Милла Йовович выложила свой проект в open-source, Claude Code нашел баг в Linux, которому 23 года, Anthropic показали Claude Mythos и сразу закрыли доступ.

А Skill Caveman внезапно оказался самым простым и самым эффективным инструментом недели.

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

Однако, если ты опытный специалист и постоянно используешь стримы в своей работе, возможно даже для тебя будет изюминка, ради которой тебе стоит прочитать статью. Я подпишу блок для тебя как ИЗЮМИНКА 

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

Начнём с того, что такое Stream и в чём его схожесть с Flux.

Если серьезно, то сегодня мы поговорим про БАЗЫ данных. Как-то один мой друг разработчик сказал, что программирование можно понимать как

Продолжая тему инструментов, интегрированных в среду разработки, сегодня мы рассмотрим клиент для работы с базами данных, доступный пользователям GigaIDE. Для пользователей Community-версии доступен open source-плагин DB Navigator, который хорошо описан, например, здесь. Пользователям PRO-версии доступна пара расширений:

SQL — синтаксическая поддержка и форматирование SQL-кода;

Database — клиент баз данных с широким набором возможностей.

Я работаю программистом 15 лет. За это время чего я только не делал и у меня скопилась статистика. Если на первом месте я работал 5 лет на втором 3 года, то на последующих год полтора и я выгорал и менял работу. Я не мог понять почему так происходило. Только в одной фирме мне действительно нравилось работать. Хотя когда я там работал мне тоже хотелось в определенный моменты уйти, но все же сейчас я вспоминаю коллег и проекты с теплотой.

Итак, вопреки утверждениям скептиков (среди которых не так давно был и я) ИИ-разработка с двух ног влетела в настоящую промышленную эксплуатацию, и мем уже совсем не тот: не джун теперь роняет прод, а нейросеть убивает статистику доступности гитхаба, амазона, Cloudflare и даже самой мекки вайб-кодинга — сервисов Anthropic и OpenAI. 

Данная статья является переводом анонса Гевина Кингa о релизе первого milestone JPA 4 спецификации и общего вектора развития JPA.

Полноценная 4-ая версия JPA спецификации должна выйти чуть-чуть позже в этом году. Тем не менее, то, что сейчас в Milestone это основа, которая, возможно, с небольшими доработками, но уже пойдёт в релиз в этом году.

От себя скажу, что данное обновление будет довольно крупное. Я оставил свои комментарии там, где посчитал уместным.

P.S: У нас в рамках Spring АйО Академии как раз есть программа посвящённая Hibernate. В ней мы тоже затронем новую версию спецификации, в частности и работу со StatelessSession и EntityAgent на практике. Я думаю, что из всего апдейта, именно стандартизация работы без Persistence Context будет самым важным для прикладных разработчиков. Остальное тоже важно, но не так как работа с EntityAgent.

Приятного чтения!

Начнем с того, как микросервисы могут общаться? На самом деле все просто, сложные приложения могут состоять из нескольких разных микросервисов.

Каждый сервис будет иметь свою логику, свою ответственность. Сервисы одной системы могут быть написаны на разных языках программирования. Однако это не будет мешать им общаться. Так вот общение это буквально - обмен информацией. Обмен сообщениями определенного формата, который смогут понять все сервисы. Это похоже на общение между нами. Я говорю что-то собеседник слушает информацию, дальше обрабатывает ее неким образом своим мыслительным аппаратом и формирует ответное сообщение и проговаривает его вслух адресуя голос в направлении оппонента. Для отправки сообщения нам людям, нужно знать адресата или видеть его, для того, чтобы обратиться к нему.

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

Если ты разработчик, то тебя это коснется. Спустя какое то время, кто-то раньше, кто-то позже, но каждый приходит к тому, что пора реально взять и разобраться в многопоточке. Я как то писал статью для себя, когда готовился к собесам и понял, что мне самому очень вкатывает такой формат обучения, когда ты пишешь статью на тему, которую исследуешь изучаешь. Так информация осваивается в разы лучше. Поэтому я собираюсь пропустить через себя огромный объем информации по многопоточности. Буду работать как супер компьютер обрабатывать сразу все возможные ветки в направлении освоения многопоточности. 

Стандартные алгоритмы даунсемплинга хорошо работают с линейными графиками. На scatter они теряют до 60% визуально значимых данных. Показываем, как двумерное прореживание решает задачу, которую одномерные методы фундаментально не могут.

Java 26 вышла 18 марта. В релизе 10 JEP-ов: Structured Concurrency получила шестое превью и API наконец стабилизировался, final-поля начинают путь к настоящей иммутабельности, G1 и ZGC получили улучшения производительности, примитивы заработали в паттернах, а HTTP/3 вошёл в стандартный HttpClient финальной фичей.

Разбираем каждое из изменений и смотрим, как перевести реальный проект на Java 26.

Честно говоря, я долго не мог решиться написать и опубликовать эту статью. Зачем, думал я, возиться с не самой популярной технологией и изобретать велосипед — реализовывать функции, которые уже где‑то есть? На этот вопрос у меня нет универсального ответа — каждому своё.

Сначала мне казалось, что рассказывать о таких «подвигах» не слишком интересно. Все любят истории об успешном успехе. Потом я вспомнил: главное — не итог, а путь, опыт и знания, которые ты получаешь по дороге. Как только я начал смотреть на материал как на обучающий, делиться им стало намного проще.

Бывает так: с какой то технологией уже разобрался, а вот перейти к новой боязно. Учить новые движки непросто, да и текущий инструмент уже не справляется с задумкой… Сомнения часто мешают двигаться вперёд, но народная мудрость «глаза боятся, а руки делают» никогда не подводит.

В итоге я решился и попробовал FXGL для 3D‑рендеринга. Но не для того, чтобы сделать полноценную игру(хотя она и получилась), а чтобы соединить расчёты по системному моделированию с элементами геймификации. Уточню: я не призываю использовать FXGL во всех случаях. Для серьёзных 3D‑проектов есть отличные инструменты — Unigine, jMonkeyEngine, Godot, Unreal Engine. Я попытался собрать и упорядочить знания, которые получил в ходе своего небольшого эксперимента.

Последние годы FeignClient и RestTemplate были де-факто стандартом для вызова внешних API в Spring. Но теперь появился нативный Http Interface Client — и я решил проверить, можно ли им заменить Feign без потери удобства.