📚обзор на ч. 4 «Предметно-ориентированное проектирование» от Эрика Эванса (Стратегическое проектирование)

ч. 1
ч. 2
ч. 3

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

единая доменная модель для большой системы почти всегда недостижима или слишком дорогая. поэтому систему делят на части — bounded contexts.

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

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

extreme programming хорошо поддерживает целостность модели внутри одного контекста, но между контекстами нужны архитектурные решения. варианты: shared kernel, customer/supplier, conformist, anticorruption layer.

anticorruption layer — изоляция своей модели через трансляцию. обычно комбинация фасада и адаптера: фасад упрощает внешний интерфейс, адаптер переводит вызовы и данные. слой может быть двусторонним, если обе системы обмениваются вызовами или событиями. минимальные изменения чужой системы допустимы, но осторожно.

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

смысловое ядро выделяют в отдельный модуль (abstract core). фундаментальные понятия становятся абстрактными классами или интерфейсами, специализированные части остаются в своих модулях. большинство ссылается на ядро, а не друг на друга.

дистилляция и углубляющий рефакторинг делают модель очевидной и гибкой. изменения кода отражают изменения в понимании предметной области: узнали что-то о бизнесе — код меняется, уточнили модель — код уточняется.

стратегическое проектирование начинается с оценки ситуации: карта контекстов, единый язык, смысловое ядро, технологии, навыки и интерес команды.

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

💎- спасибо за обзор книги!

Что за CDC и Debezium такие?💻

В предыдущих постах я рассказывала о миграции данных и упомянула Debezium как целевое решение, поэтому хотелось бы рассказать о нём чуть подробнее.
Репозиторий проекта: https://github.com/debezium/debezium

Change Data Capture (CDC, захват изменений данных) — это технология, которая позволяет отслеживать и фиксировать изменения в базе данных в реальном времени, а затем передавать эти данные в другие системы. Возможно, в кабанчике про это читали, если не работали напрямую.

Debezium - это CDC-платформа, которая использует все блага Apache Kafka и Kafka Connect для обеспечения надежности, отказоустойчивости и масштабируемости.

Коннектор Kafka Connect отслеживает базу данных, считывает все изменения и публикует их в Kafka-топики. Также Debezium можно запускать через embedded-движок прямо внутри приложения, получая те же события изменений данных без использования Kafka. Ещё один вариант — поставить целый Debezium Server (готовое к использованию приложение). Подробнее об архитектуре

Debezium полезен в ряде следующих сценариев: инвалидация кеша, интеграция, миграция данных, CQRS.

Как же это работает на практике? На примере миграции Oracle -> PostgreSQL.
Oracle фиксирует все изменения в redo log. При первом запуске коннектора Debezium делает initial snapshot — полное считывание состояния таблиц. После snapshot-а коннектор продолжает стримить изменения из redo log, превращая INSERT / UPDATE / DELETE в упорядоченные CDC-события, которые отправляются в Kafka. Далее sink-коннектор или consumer применяет эти изменения к PostgreSQL, воспроизводя операции в том же порядке. В результате Postgres постепенно синхронизируется с Oracle. Важно: Oracle должен быть настроен на архивное логирование

Что доступно сейчас?
Source-коннекторы поддерживают: MongoDB, MariaDB, MySQL, PostgreSQL, Oracle, SQL Server, Db2, Cassandra, Spanner и Vitess + Informix (инкубационный режим).
Sink-коннекторы — JDBC и MongoDB Sink.

Для раската миграции мне понадобились образы Kafka (Kafka, Zookeeper, Kafka UI, Kafka Connect UI) и Debezium Connect. UI мной был проигнорирован умышленно, так как летом 2025 он был сырым и нерабочим. На февраль 2026 репозиторий UI уже архивирован, так как появилась новая платформа с UI: разработка идёт активно, но проект пока на ранней стадии.

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

😭как правильно жаловаться на баг? давайте разбираться.

когда задаёшь вопрос на том же Stackoverflow или issue на GitHub с подозрением на баг, важно дать такой код, чтобы другие могли быстро понять и воспроизвести проблему. в англоязычном сообществе это называют MRE / MCVE / MWE / reprex = минимальный, воспроизводимый пример.

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

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

что такое полный? чтобы другой разработчик смог повторить баг быстро прямо из примера. red flag - это вставлять скриншоты кода. всегда стоит использовать отдельные текстовые блоки для каждого фрагмента.

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

если соблюдать эти три основные правила, люди гораздо быстрее помогут разобраться или создать PR.

также советую к прочтению эту статью.

💎 - полезно, дарреровна

⚡️ активно слежу за проектами в экосистеме Java. пару лет назад коллеги рассказывали мне про JPA Buddy, и инструмент сразу заинтересовал. очень быстро он стал хитом: на сегодня у него 5 миллионов скачиваний, его заметили в JetBrains, и он вошёл в продуктовую линейку компании.

после этого ребята из Haulmont начали работать над Amplicode, чтобы расширить возможности интеграций с разными средами и дать всем Spring-разработчикам доступ к современным инструментам. также вместе с компаниями Axiom JDK и Группой Астра они создали и продолжают развивать открытый бесплатный российский форк IntelliJ IDEA Community — OpenIDE.

Amplicode — это плагин для IntelliJ IDEA (Community и Ultimate), GigaIDE и OpenIDE, который ускоряет и упрощает разработку сервисов и web-приложений на Spring. А версия для VS Code позволяет быстро создавать административный интерфейс на React Admin.

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

💻миграция на Spring Boot 3 (Java 17): особенности процесса

да, понимаю: звучит как тема из 2022 года.
но по опросам здесь около 20% всё ещё работают на старых версиях. так что, возможно, кому-то будет полезно увидеть верхнеуровневую картину миграции (или кого в целом обошла такая участь на проекте)

наш проект был на Java 11 + Spring Boot < 2.7.
Spring Boot 3 требует минимум Java 17, поэтому логичный первый шаг - это обновление Java.

⛏этап 1. переезд на Spring Boot 2.7 + Java 17
это своего рода мост.
что происходит на этом этапе:
• обновление Java 11 → 17
• обновление Spring Boot → 2.7
• обновление зависимостей
• небольшие правки в application.properties / yaml
• начинают светиться deprecated-конфигурации

основная боль - это зависимости. в целом, работа достаточно быстрая и техническая.

⛏этап 2: переезд на Spring Boot 3
а вот тут начинается самое интересное.

• главное изменение - переход с Java EE на Jakarta EE. Все пакеты javax.* стали jakarta.*, и это затрагивает JPA, Validation, Servlet API, кастомные фильтры и интеграции.
• Hibernate 6 теперь используется в Spring Boot 3. меняется поведение ORM: может измениться генерируемый SQL, стратегии именования, поведение join’ов, pagination. иногда внезапно проседает производительность запросов, которые раньше работали стабильно, приходится разбираться, что поменялось под капотом.
• Spring Cloud Sleuth больше не поддерживается, вместо него используется Micrometer Tracing. также меняются конфигурации Spring Security, Feign, Actuator, Prometheus и другие коровые компоненты. есть изменения в springdoc-openapi, логировании (Logback) и поведении MVC. например, сопоставление URL с завершающим слэшем теперь отключено по умолчанию: /api/test и /api/test/ считаются разными маршрутами, что может повлиять на api-gateway.
• Actuator стал более строгим по умолчанию. подход к отображению чувствительных конфигурационных значений изменён в сторону большей безопасности, что тоже может потребовать корректировки настроек.
• тесты после перехода часто начинают падать из-за Jakarta, обновлённых конфигураций и изменений во фреймворке. где-то нужно переписать конфигурацию, обновить моки, поменять импорты.

spring boot migrator - это инструмент, который помогает автоматически мигрировать проекты на новые версии Spring Boot. он сканирует код и конфигурации, находит устаревшие элементы и предлагает изменения, чтобы проект корректно работал с актуальной версией: своего рода помощник при крупных апгрейдах, чтобы уменьшить ручную работу и ошибки.

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

ах! юбилей! 💻🤭
спасибо, что читаете, друзья

🏀собери команду из покемонов…
или из ии-агентов.

в Claude Code представили новую экспериментальную функцию — Agent Teams. она позволяет запускать не одного ai-ассистента, а сразу несколько агентов, которые работают вместе над одной задачей. по сути, это полноценная команда разработчиков-ии: есть тимлид, есть исполнители с разными ролями, есть распределение ответственности.

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

в документации приводят несколько сценариев:

🎮parallel code review — несколько агентов проверяют один pr с разных сторон: безопасность, производительность, тесты.
🎮debugging with competing hypotheses — агенты параллельно проверяют разные гипотезы бага и сопоставляют выводы.
🎮реализация фичи — один отвечает за backend, другой за frontend, третий за тесты и документацию.

из нюансов: токенов тратится ощутимо больше, и задачи желательно декомпозировать так, чтобы они были максимально независимыми.

и вот интересный кейс: команда из 16 агентов за две недели и примерно 20 000 долларов без вмешательства людей создала 100 000-строчный компилятор C на базе Rust, способный компилировать ядро Linux.

бу, испугался?