GRASP: почему настоящая архитектура начинается не с SOLID

Хочу начать с личной предыстории. Давным‑давно, как и многие из вас, я читал умные книжки: «Чистый код» и «Чистая архитектура» Роберта Мартина, «Совершенный код» Стива Макконнелла и другие.

Также не обошли меня и классические принципы проектирования — SOLID, KISS, DRY — и, думаю, каждый читатель добавит сюда свои.

Безусловно, это всё важные и фундаментальные вещи.

Но однажды на горизонте появилось DDD — предметно‑ориентированное проектирование в изложении Эрика Эванса. Именно его «синяя книга» стала культовой и задала язык для архитектурного мышления.

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

Читая Эванса, рассматривая его диаграммы классов и примеры кода, я всё думал: как он это делает?

https://habr.com/ru/articles/900140/

👉@BookJava

Остался всего 1 день, чтобы прокачать асинхронный код на Scala Future 📢

15 апреля в 18:30 пройдёт открытый вебинар с Валентином Шилиным — старшим программистом и аналитиком данных Deutsche Telekom IT GmbH, экспертом по большим данным и преподавателем курсов по Scala и Apache Spark. Он расскажет:

— как избегать типичных ошибок (блокировки и потерю контекста)
— как комбинировать асинхронные операции (Future.sequence, traverse, for-comprehensions)
— как ускорить и упростить написание кода на Scala

❗️ Если вы хотите перейти с Java на Scala или уже используете Play Framework, Akka или Spark — на вебинаре вы узнаете, как грамотно писать асинхронный код и устранять «подводные камни».

Каждый участник:
— сможет задать вопросы эксперту
— получит скидку на полный курс по Scala-разработке

👉 Не упустите шанс перейти на новый уровень — регистрируйтесь, остался 1 день

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

🧠 Частая ловушка при работе с @Transactional в Spring

Сейчас покажу вам один распространённый анти-паттерн, который легко пропустить — вызов транзакционного метода внутри того же класса.

📌 Пример:

@Service
public class UserService {

    @Transactional
    public void registerUser(UserDto dto) {
        saveUser(dto);
    }

    @Transactional
    public void saveUser(UserDto dto) {
        // сохранение пользователя
    }
}

💥 Проблема:
Spring не применит транзакцию к saveUser(), потому что вызов происходит внутри одного и того же бина — минуя прокси.

Spring AOP работает через прокси, и @Transactional "срабатывает", только если метод вызывается извне, через прокси-объект.

⚠️ Это может привести к очень странным багам: вы думаете, что транзакция есть, а её нет.

💡 Как исправить:

1. Вынести метод в отдельный бин:

@Service
public class UserSaver {
    @Transactional
    public void save(UserDto dto) {
        // сохраняем
    }
}

@Service
public class UserService {
    private final UserSaver saver;

    public UserService(UserSaver saver) {
        this.saver = saver;
    }

    public void registerUser(UserDto dto) {
        saver.save(dto);
    }
}

2. Или использовать TransactionTemplate вручную.

✅ Всегда проверяйте, как вызываются методы с @Transactional. Особенно при рефакторинге!

👉@BookJava

❓ Разработчики, интересуетесь стримингом, хайлоадом и видеотехнологиями?

⏰ 22 апреля на митапе VK Видео техлиды и топ-менеджеры расскажут, как, например, устанавливают CDN.

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

🎯 Узнаете, как устроена архитектура VK Видео, как выстроены команды и какие задачи сейчас в приоритете.

👉Загляните под капот VK Видео

🧠 Как ускорить cold start Spring Boot приложения

Как можно сократить время старта Spring Boot 3+ приложения — без GraalVM и без магии.

📌 Используем флаг:

-Dspring.context.cache.applicationContext=true

💡 Что это такое?
Это встроенный механизм кэширования ApplicationContext, появившийся в Spring Boot 3.2.

Он сохраняет результат построения контекста и позволяет повторно использовать его между запусками, особенно в тестах и development-сценариях.

⚙️ Как работает:
- При первом запуске контекст билдится как обычно.
- Затем сериализуется и сохраняется на диск.
- При следующем запуске он подгружается из кеша (если не изменился), что даёт ускорение в 2-3 раза и больше.

🚀 Отлично подходит для:
- Тестов (@SpringBootTest);
- Dev tools и локального запуска;
- Разработки больших монолитов.

⚠️ Не влияет на продакшн (там кеш не используется по умолчанию)
⚠️ Не поддерживает все конфигурации (например, динамические настройки могут инвалидировать кеш)

Простой флаг — а экономит кучу времени каждый день.

👉@BookJava

🧠 ThreadLocal — скрытая угроза утечек памяти

ThreadLocal — удобный способ хранить данные, привязанные к потоку. Например, для SimpleDateFormat или текущего пользователя в рамках запроса. Но с ним легко получить утечку памяти, особенно в thread pool'ах.

📌 Почему?
ThreadLocal-хранилище (Thread.threadLocals) живёт столько же, сколько поток. А потоки из пулов живут долго. Если ты забыл вызвать remove() — данные останутся в памяти навсегда.

Пример:

private static final ThreadLocal<UserContext> context = ThreadLocal.withInitial(UserContext::new);

public void handleRequest() {
    try {
        context.set(new UserContext("user123"));
        // работа с контекстом
    } finally {
        context.remove(); // ОБЯЗАТЕЛЬНО!
    }
}

⚠️ Что пойдёт не так без remove()?

- Поток из пула закончит обрабатывать запрос, но UserContext останется висеть в ThreadLocalMap этого потока.
- Если UserContext содержит ссылки на другие объекты (например, HttpSession, EntityManager и т.д.) — вся эта цепочка не будет GC-шиться.
- И так накапливается утечка.

💡 Советы:

- Всегда вызывай remove() в finally.
- Для Spring можно использовать RequestScope или @ControllerAdvice вместо ThreadLocal.
- Проверяй код сторонних библиотек, если они используют ThreadLocal, особенно в фильтрах и интерсепторах.

👉@BookJava

❓Сталкиваетесь с задачами, когда вам нужно выбрать лучший алгоритм, но не понимаете, как анализировать их сложность? Ваш код может быть медленным или неэффективным, и вы не знаете, как это исправить?

📗На открытом вебинаре 21 апреля в 20:00 мск вы освоите важные инструменты для анализа сложности алгоритмов, улучшите свой навык решения алгоритмических задач и на примере простых алгоритмов сортировки и увидите разницу при применении алгоритмов разной степени сложности.

➡️Регистрируйтесь прямо сейчас и получите скидку на большое обучение «C# Developer» по промокоду SHARP_SPEC_4: https://vk.cc/cKRCrB

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

💡 Ленивая инициализация бинов в Spring Boot — мощный инструмент ускорения старта

По умолчанию Spring инициализирует все singleton-бины при запуске приложения. Это может быть проблемой в больших проектах: старт медленный, а половина бинов не нужна сразу.

📌 Как ускорить старт и снизить потребление памяти? — Lazy Init!

✅ Глобально:

spring:
  main:
    lazy-initialization: true

Все бины станут ленивыми — создадутся только при первом обращении. Это может сократить старт приложения на 30-60%!

✅ Локально (избирательно):

@Component
@Lazy
public class HeavyBean {
    public HeavyBean() {
        System.out.println("HeavyBean init...");
    }
}

Или через @Lazy на зависимостях:

@Service
public class MyService {
    public MyService(@Lazy HeavyBean heavyBean) {
        this.heavyBean = heavyBean;
    }
}

🧠 Когда использовать:

- В dev-окружении — чтобы ускорить локальный dev cycle.
- В CLI/Batch-приложениях, где используется 1-2 бина.
- Когда есть тяжёлые бины, не нужные на старте (например, интеграции, большие клиенты и т.п.).

⚠️ Осторожно:

- Если забыть @Lazy на зависимостях, Spring всё равно создаст бин.
- Некоторые бины должны быть загружены сразу (например, @Scheduled, @EventListener), иначе они не сработают.

👉@BookJava

🧠 Как ускорить загрузку контекста Spring Boot — простой приём

Если у вас тяжёлый Spring Boot-приложение с кучей конфигураций и бинов, время старта может легко вырасти до 20–30 секунд и больше. Сегодня покажу приём, который помогает ускорить cold start за счёт отключения ненужных автоматических конфигураций.

📌 Spring Boot автоконфигурация — это палка о двух концах.
Она упрощает старт, но часто тянет за собой кучу лишнего. Особенно если вы используете @SpringBootApplication, которая включает в себя @EnableAutoConfiguration.

💡 Решение — использовать spring.autoconfigure.exclude, чтобы явно выключить ненужное. Например:

# application.yaml
spring:
  autoconfigure:
    exclude:
      - org.springframework.boot.autoconfigure.web.servlet.error.ErrorMvcAutoConfiguration
      - org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration

❗️Это особенно актуально:
- в микросервисах без UI (отключаем MVC)
- если datasource создаётся вручную
- в тестах и lightweight-режимах

👀 Как понять, что мешает?
1. Запусти приложение с флагом --debug или логгером org.springframework.boot.autoconfigure уровня DEBUG.
2. Посмотри, какие автоконфигурации "matched", но тебе не нужны.
3. Добавь их в exclude.

🧰 Альтернатива — использовать аннотацию @ImportAutoConfiguration с явным списком нужных автоконфигураций. Это тонкая настройка, идеально для библиотек и SDK.

⚠️ Не переусердствуй: отключение нужной конфигурации может привести к тихим багам. Лучше вырезать по одной и смотреть на эффект.

👉 Это один из способов сделать Spring Boot предсказуемым и быстрым, особенно в CI/CD или serverless-окружениях.

👉@BookJava

🧠 Простое ускорение @Transactional методов в Spring Boot

Знаете, что @Transactional по умолчанию оборачивает метод в прокси?

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

📌 Если вы точно знаете, что метод будет вызываться только извне, и вам не нужна прокси-обёртка — используйте @Transactional на уровне интерфейса и включите interface-based proxy.

@Configuration
@EnableTransactionManagement(proxyTargetClass = false) // JDK proxy
public class TransactionConfig {
}

public interface UserService {
    @Transactional
    void createUser(User user);
}

📉 Это немного снижает overhead, особенно в высоконагруженных сервисах, где сотни тысяч вызовов @Transactional-методов.

💡 Подходит, если:
- У вас слоистая архитектура;
- Транзакции нужны только снаружи;
- Вы не используете вызовы this.someMethod() внутри сервиса.

⚠️ Не забывайте:
- JDK Proxy работает только с интерфейсами;
- Если вызываете методы внутри того же класса — прокси не сработает (и транзакция не начнётся).

📊 Профильте. Иногда замена proxyTargetClass = true на false даёт +3-5% к throughput.

👉@BookJava

Хотите глубже разобраться в функциональном программировании и писать более качественный код на Scala? Приходите на вебинар в Otus

24 апреля в 20:00 пройдёт открытый вебинар с Алексеем Воронцом — руководителем разработки в Naumen, 14 лет опыта, из них 9 лет на Scala. На практических примерах он покажет:

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

❗️ Если вы уже знакомы со Scala или только начинаете к нему присматриваться и хотите развивать функциональный подход в своих проектах — этот вебинар для вас.

Каждый участник:
— сможет задать вопросы эксперту
— получит скидку на полный курс по Scala-разработке

👉 Регистрируйтесь и сделайте свой код лучше

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

🧠 Сейчас покажу баг, который легко пропустить при работе с @Transactional в Spring Boot 3+.

📌 Проблема — транзакция не работает, потому что метод вызывается изнутри того же класса.

Рассмотрим пример:

@Service
public class UserService {

    @Transactional
    public void createUser(User user) {
        saveUser(user);
        sendWelcomeEmail(user); // бросает исключение
    }

    public void saveUser(User user) {
        userRepository.save(user);
    }
}

💥 Если sendWelcomeEmail выбросит исключение — транзакция не откатится, потому что @Transactional работает через прокси. Вызов createUser() должен идти извне, чтобы Spring "знал", что нужно обернуть вызов в транзакцию.


✅ Решения:

1. Вынести transactional-метод в отдельный бин:

   @Service
   public class UserCreationService {
       @Transactional
       public void createUser(User user) {
           // ...
       }
   }
   

2. Внедрить self-прокси:

   @Autowired
   private UserService self;

   public void externalCaller(User user) {
       self.createUser(user);
   }
   

3. Использовать AopContext:

   ((UserService) AopContext.currentProxy()).createUser(user);
   

⚠️ Не забудь включить exposeProxy = true в @EnableAspectJAutoProxy.


💡 Современный подход — разделение ответственности: transactional-методы живут в отдельных сервисах, их проще тестировать и не возникает подобных ловушек.

👉@BookJava

🧠 Lazy Initialization по-взрослому: не создавай проблемы на ровном месте

В Spring Boot часто можно встретить вот такую конструкцию:

@Service
public class EmailService {
    private final SmtpClient client = new SmtpClient(); // дорогая инициализация
}

⚠️ Проблема: SmtpClient создаётся сразу при старте приложения. Даже если EmailService ни разу не вызовется. Это не только waste of resources, но и может сломать запуск, если SmtpClient требует специфического окружения.

📌 Решение — ленивая инициализация, но не через старый добрый null-check, а красиво, безопасно и читаемо:

💡 Способ #1: Lazy<T> wrapper

@Component
public class EmailService {
    private final Supplier<SmtpClient> client = Suppliers.memoize(SmtpClient::new);

    public void sendEmail(...) {
        client.get().send(...);
    }
}

Можно и без Guava:

public class Lazy<T> {
    private Supplier<T> supplier;

    public Lazy(Supplier<T> supplier) {
        this.supplier = () -> {
            T value = supplier.get();
            this.supplier = () -> value;
            return value;
        };
    }

    public T get() {
        return supplier.get();
    }
}

💡 Способ #2: через Spring

@Service
public class EmailService {
    private final ObjectProvider<SmtpClient> client;

    public EmailService(ObjectProvider<SmtpClient> client) {
        this.client = client;
    }

    public void sendEmail(...) {
        client.getObject().send(...);
    }
}

🧵 Итог:
- Не инициализируй тяжёлые объекты зря.
- Используй Supplier, ObjectProvider или Lazy<T>.
- Это особенно критично для тестов, лямбд и кэширования.

👉@BookJava

🧠 Spring Boot 3.2+: ускоряем стартап с помощью application.metrics.export.observation.enabled=false

Spring Boot 3.2 по умолчанию включает сбор Micrometer Observation метрик — даже если вы не используете Prometheus, Datadog и пр.
Это полезно, но часто избыточно — особенно в микросервисах, где важна скорость старта.

📌 Что это даёт?

- Отключает автоконфигурацию ObservationRegistry
- Убирает связанные Bean'ы
- Сокращает время старта до 30-60% (в зависимости от контекста)

💡 Как применить?

В application.yml или application.properties:

management:
  metrics:
    export:
      observation:
        enabled: false

Или так, если используешь .properties:

management.metrics.export.observation.enabled=false

⚠️ Важно: это не отключает другие метрики Micrometer.
Это касается только новой подсистемы Observation — она полезна для трассировки, но не всегда нужна.

📎 Документация Micrometer Observation

👉@BookJava

🧠 Spring Boot и медленные autowire — проверь, не зарыта ли у тебя бомба в @Configuration

Есть распространённый анти-паттерн: ты используешь @Configuration и внутри создаёшь бины с @Bean, а в этих методах — инжектишь зависимости через параметры. Всё выглядит красиво и «по фэншую»... но только на первый взгляд.

@Configuration
public class MyConfig {

    @Bean
    public MyService myService(SomeDep dep) {
        return new MyService(dep);
    }

    @Bean
    public SomeDep someDep() {
        return new SomeDep();
    }
}

⚠️ Проблема: такие методы вызываются при старте контекста, и если SomeDep создаётся долго (например, подтягивает настройки из удалённого конфига, делает init-запрос в БД, или тянет секьюрити-контекст), это тормозит весь старт.

📌 Хуже всего, если ты не подозреваешь об этом: ведь @Bean -методы не видны как "инициализация", и кажется, что контекст тормозит "где-то ещё".

💡 Совет:
- Используй @Lazy в нужных местах, особенно если bean тяжёлый или редко используется.
- Разделяй конфигурацию: отдельно core, отдельно init-heavy.
- Не бойся отказаться от @Configuration в пользу @Component + @Service, если это упрощает понимание.

И главное — профилируй старт. spring-boot-starter-actuator + --debug могут открыть глаза.

👉@BookJava

Осталось всего 2 дня — углубитесь в функциональное программирование на Scala в Otus 📢

24 апреля в 20:00 пройдёт открытый вебинар с Алексеем Воронцом — руководителем разработки в Naumen, 14 лет опыта, из них 9 лет на Scala. Он расскажет:

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

Если вы уже знакомы со Scala или желаете перейти на него и хотите развивать функциональный подход в своих проектах — этот вебинар для вас.

Каждый участник:
— сможет задать вопросы эксперту
— получит скидку на полный курс по Scala-разработке

👉 Не упустите возможность перейти на новый уровень — регистрируйтесь, осталось 2 дня до начала

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

🧠 JPA: не забывай про flush() перед clear() — иначе словишь баг

Если ты используешь EntityManager вручную, например, при батчевой вставке или обновлении, то, скорее всего, пишешь что-то вроде:

for (int i = 0; i < entities.size(); i++) {
    em.persist(entities.get(i));
    if (i % 50 == 0) {
        em.clear(); // чтобы не росла память
    }
}

⚠️ Но тут баг: без flush() перед clear() ты теряешь все неперсистенные изменения! Hibernate просто забудет про них.

✅ Правильно так:

for (int i = 0; i < entities.size(); i++) {
    em.persist(entities.get(i));
    if (i % 50 == 0) {
        em.flush();
        em.clear();
    }
}

📌 flush() гарантирует, что все накопленные изменения пойдут в базу, а clear() уже безопасно очищает контекст.

💡 Эта ошибка особенно коварна, потому что не всегда проявляется — зависит от настроек, триггеров в БД, кэша и т.д.

👉@BookJava

Чем отличаются checked и unchecked исключения в java?

В Java исключения делятся на два основных типа: checked и unchecked. Разница между ними ключевая и касается как обработки, так и структуры кода.

✅ Checked Exceptions (Проверяемые исключения)

Примеры: IOException, SQLException, FileNotFoundException

Отличия:
1. Проверяются компилятором — вы обязаны либо обработать их с помощью try-catch, либо явно пробросить (throws) в сигнатуре метода.
2. Производные от Exception, но не от RuntimeException.
3. Используются для ситуаций, которые можно разумно ожидать и обработать (например, отсутствие файла, проблемы с сетью).

Пример:

public void readFile(String path) throws IOException {
    FileReader reader = new FileReader(path);  // может выбросить IOException
}

❌ Unchecked Exceptions (Непроверяемые исключения)

Примеры: NullPointerException, ArrayIndexOutOfBoundsException, IllegalArgumentException

Отличия:
1. Не проверяются компилятором — вы не обязаны их обрабатывать или декларировать.
2. Производные от RuntimeException.
3. Возникают в результате ошибок в логике программы или непредвиденных ситуаций.

Пример:

public void printLength(String str) {
    System.out.println(str.length());  // может выбросить NullPointerException
}

Если кратко:

Checked — ошибки среды, требующие явной обработки.

Unchecked — ошибки в логике, ответственность программиста.

👉@BookJava