Java Разработка

Совет по Spring Boot💡 Когда вам нужно настроить bean, предоставляемый Spring Boot, проверьте наличие интерфейсов *Customizer - велика вероятность, что вы сможете настроить bean, не отказываясь от автоконфигурации. 👉 @BookJava

От 1 до миллиона пользователей (Масштабирование) Представьте: вы написали крутой стартап. Он крутится на дешевом сервере за $5 в месяц. База данных, бэкенд и фронтенд лежат в одном месте. Вдруг о вас снимает ролик популярный блогер. Трафик вырастает в 10,000 раз. Сервер ложится через 3 секунды от OutOfMemoryError. Бизнес теряет деньги. Что делать? У вас есть два пути масштабирования (Scaling). 📈 1. Вертикальное масштабирование (Scale Up) Это самый простой и интуитивный подход. Сервер не справляется? Давайте купим сервер мощнее! Было 2 ГБ оперативки - поставим 128 ГБ. Был 1 ядерный процессор - купим 64-ядерный. 🔴 Плюсы: Не нужно менять ни строчки кода. Всё просто работает быстрее. 🔴 Минусы: 1. Физический предел. Вы не можете купить сервер с бесконечной памятью. Самый мощный сервер рано или поздно закончится. 2. SPOF (Single Point of Failure). Единая точка отказа. Каким бы мощным ни был сервер, если уборщица выдернет шнур питания в дата-центре - ваш бизнес остановится. 🌐 2. Горизонтальное масштабирование (Scale Out) Это путь настоящих джедаев и BigTech-компаний. Вместо покупки одного суперкомпьютера за миллион долларов, мы покупаем 1000 дешевых обычных серверов и заставляем их работать вместе. 🔴 Плюсы: Масштабирование практически бесконечно. Упал один сервер? Ничего страшного, трафик подхватят остальные 999. 🔴 Минусы: Архитектура становится в разы сложнее. Появляется куча новых проблем: как делить трафик, как синхронизировать данные, как хранить сессии. ⚖️ 3. Балансировщик нагрузки (Load Balancer) Допустим, мы выбрали горизонтальное масштабирование и запустили 5 одинаковых серверов с нашим Spring Boot приложением. Но пользователи (клиенты) знают только один домен: mysite.com. Как сделать так, чтобы запросы распределялись между этими пятью серверами равномерно? Перед нашими серверами встает Load Balancer (Балансировщик) - например, Nginx, HAProxy или облачный AWS ALB. Пользователь стучится в Балансировщик, а тот перенаправляет запрос на наименее загруженный сервер. 🔴 Round Robin: Самый простой алгоритм. Запросы раздаются по кругу: первому серверу, второму, третьему, первому, второму... 🔴 Least Connections: Запрос уходит на тот сервер, у которого сейчас меньше всего активных соединений. 🧠 4. Главное правило: Stateless (Без состояния) Горизонтальное масштабирование ломает старый подход к хранению сессий. Если пользователь залогинился и попал на Сервер №1, этот сервер сохранил его данные в оперативной памяти. При следующем клике балансировщик может кинуть пользователя на Сервер №2. А Сервер №2 скажет: "Я тебя не знаю, авторизуйся заново". Решение: Серверы приложения должны быть "глупыми" и ничего не помнить (Stateless). Состояние должно храниться в общем внешнем хранилище (например, в Redis, как мы обсуждали в прошлых сезонах), либо передаваться прямо в запросе с помощью токенов (JWT). 🔥 Итог 1. Vertical Scaling (вверх) - купить "железо" помощнее. Дорого, есть предел. 2. Horizontal Scaling (вширь) - поставить больше дешевых серверов. Требует изменения архитектуры. 3. Load Balancer - дирижер, который распределяет трафик между клонами. 4. Stateless - обязательное условие. Приложение не должно хранить локальное состояние. #SystemDesign #Architecture #Scaling #LoadBalancing #Backend 👉 @BookJava

🕸️ Распределенная Трассировка: Ищем "бутылочное горлышко" (Zipkin & Jaeger) Если логи это текст, а метрики это графики, то трассировка это диаграмма Ганта (каскад) для каждого отдельного HTTP-запроса. 🧩 Главные понятия: Trace и Span Вся магия строится на двух терминах: 1. Trace (След/Трасса): Это весь путь запроса от клика пользователя в браузере до самого глубокого ответа от базы данных. У него есть единый Trace ID. 2. Span (Пролет/Отрезок): Это один конкретный шаг внутри Трассы. Например, "поход в базу данных" - это один Span. "HTTP-запрос в сервис оплаты" - это другой Span. У каждого спана есть свой Span ID и информация о том, сколько миллисекунд он выполнялся. 🕵️‍♂️ Как сервисы передают ID друг другу? Когда Gateway принимает запрос, он генерирует Trace ID (например, abc-123) и кладет его в HTTP-заголовки (обычно используется стандарт W3C traceparent или b3). Когда Gateway вызывает OrderService, он передает эти заголовки дальше. OrderService читает их и понимает: "Ага, я часть большой трассы abc-123". Вам не нужно писать этот код руками! В Spring Boot 3 за это отвечает библиотека Micrometer Tracing. Она автоматически перехватывает все вызовы через RestTemplate, WebClient, Feign и запросы к БД, вклеивая туда нужные ID. 🛠 Настройка (Spring Boot 3 + Zipkin) Вам нужно добавить всего пару зависимостей в pom.xml: io.micrometer micrometer-tracing-bridge-brave io.zipkin.reporter2 zipkin-reporter-brave В application.yaml указываем адрес сервера Zipkin: management: tracing: sampling: probability: 1.0 # Отправлять 100% запросов (на проде обычно ставят 0.1, чтобы не грузить сеть) zipkin: tracing: endpoint: "http://localhost:9411/api/v2/spans" Ваши микросервисы в фоновом режиме отправляют данные о спанах (время старта и конца) в специальный сервер. Самые популярные решения это Zipkin (написан на Java, проще) или Jaeger (от Uber, написан на Go, мощнее). Вы заходите в веб-интерфейс Jaeger, вбиваете Trace ID (который вы скопировали из логов в Kibana) и видите красивую цветную лесенку: 🟦 Gateway (Всего: 5.0s) 🟩 OrderService.create() (4.9s) 🟨 DB: INSERT order (0.05s) 🟧 PaymentService.pay() (4.8s) 👈 АГА! ВОТ КТО ТОРМОЗИТ! 🟥 External Bank API (4.75s) За 5 секунд вы поняли, что проблема не в вашем коде и не в вашей базе данных, а в том, что API стороннего банка отвечает почти 5 секунд. Вы сэкономили часы дебага! 🔥 Итог: "Святая Троица" Observability Теперь у вас есть полный набор инструментов Senior-разработчика: 1. Метрики (Prometheus/Grafana): Говорят ЕСТЬ ЛИ проблема. (У нас всплеск 500-х ошибок!). 2. Трассировка (Jaeger/Zipkin): Говорит ГДЕ проблема. (Ошибки летят из Payment Service при походе в банк). 3. Логи (ELK): Говорят В ЧЕМ проблема. (Смотрим логи Payment Service по Trace ID и видим: ConnectionTimeoutException). #DevOps #Jaeger #Zipkin #Tracing #Microservices #SpringBoot 👉 @BookJava

🚀 Подборка полезных IT каналов в Max Системное администрирование, DevOps 📌 https://max.ru/i_odmin Все для системного администратора https://max.ru/bash_srv Bash Советы https://max.ru/sysadminof Книги для админов, полезные материалы https://max.ru/i_odmin_book Библиотека Системного Администратора https://max.ru/i_devops DevOps: Пишем о Docker, Kubernetes и др. 1C разработка 📌 https://max.ru/odin1c_rus Cтатьи, курсы, советы, шаблоны кода 1С Программирование C++📌 https://max.ru/cpp_lib Библиотека C/C++ разработчика Программирование Python 📌 https://max.ru/python_of Python академия. https://max.ru/BookPython Библиотека Python разработчика Java разработка 📌 https://max.ru/bookjava Библиотека Java разработчика GitHub Сообщество 📌 https://max.ru/githublib Интересное из GitHub Базы данных (Data Base) 📌 https://max.ru/database_info Все про базы данных Фронтенд разработка 📌 https://max.ru/frontend_1 Подборки для frontend разработчиков Библиотеки 📌 https://max.ru/programmist_of Книги по программированию https://max.ru/proglb Библиотека программиста https://max.ru/bfbook Книги для программистов Программирование 📌 https://max.ru/bookflow Лекции, видеоуроки, доклады с IT конференций https://max.ru/itmozg Программисты, дизайнеры, новости из мира IT https://max.ru/php_lib Библиотека PHP программиста 👨🏼‍💻👩‍💻 Шутки программистов 📌 https://max.ru/itumor Шутки программистов Защита, взлом, безопасность 📌 https://max.ru/thehaking Канал о кибербезопасности https://max.ru/xakkep_1 Хакер Free Книги, статьи для дизайнеров 📌 https://max.ru/odesigners Статьи, книги для дизайнеров Математика 📌 https://max.ru/Pomatematike Канал по математике https://max.ru/phismat_1 Обучающие видео, книги по Физике и Математике Вакансии 📌 https://max.ru/progjob Вакансии в IT Мир технологий 📌 https://max.ru/mir_teh Канал для любознательных Бонус 📌 https://max.ru/piterspb_78 Свежие новости Санкт-Петербурга https://max.ru/mockva_life Свежие новости Москвы

🪵 ELK Stack: Гугл для ваших логов ELK - это аббревиатура трех инструментов, которые стали стандартом индустрии: 1. Elasticsearch (База данных). 2. Logstash (Труба). 3. Kibana (Интерфейс). В современном мире к ним часто добавляется Filebeat (или Fluentd), и стек превращается в EFK. 🏗 Как это работает? (Архитектура) Представьте конвейер: 1. Java App: Просто пишет логи в консоль (STDOUT) в формате JSON. 2. Filebeat: Маленький агент, который стоит на каждом сервере (или в каждом Поде K8s). Он "слушает" консоль приложения, собирает строки и отправляет их дальше. 3. Logstash: (Опционально) Фильтрует и обрабатывает логи (например, скрывает пароли, парсит даты). 4. Elasticsearch: Хранит терабайты логов и позволяет искать по ним мгновенно. 5. Kibana: Сайт, на который вы заходите, чтобы увидеть графики и поиск. 📝 1. JSON Logging: Забудьте про текст Обычные логи Java выглядят так: 2023-10-25 INFO [main] UserService: User created Это плохо. Компьютеру сложно понять, где тут дата, а где сообщение. В микросервисах мы пишем логи в JSON: { "timestamp": "2023-10-25T10:00:00", "level": "INFO", "logger": "UserService", "message": "User created", "user_id": "123", "trace_id": "abc-987" } Как сделать в Spring Boot? Подключаем библиотеку logstash-logback-encoder и настраиваем logback-spring.xml. Теперь ваши логи это структурированные данные, по которым можно фильтровать! 🔍 2. Correlation ID (Trace ID) - Самое важное! Представьте ситуацию: User - Service A - Service B - Service C (Ошибка!). Вы видите ошибку в логах Service C. Но кто её вызвал? Какой пользователь? С какого запроса всё началось? Без связующей нити вы потратите часы на расследование. Решение: Micrometer Tracing (бывший Spring Cloud Sleuth). Он автоматически добавляет Trace ID и Span ID в каждый лог. • Trace ID: Одинаковый для всей цепочки запросов (от входа пользователя до базы данных). • Теперь в Kibana вы просто вбиваете trace_id="abc-987" и видите все логи всех сервисов, которые участвовали в этом конкретном запросе. 📊 3. Kibana: Визуализация Kibana — это не просто поиск. Это аналитика. Вы можете построить дашборд: • Круговая диаграмма: Распределение ошибок по типам (NPE, DatabaseTimeout). • График: Количество логинов в минуту. • Таблица: Топ-10 самых медленных SQL-запросов (если вы логируете время выполнения). 🛠 Pro-Tip: MDC (Mapped Diagnostic Context) Хотите, чтобы в каждом логе автоматически писался ID текущего пользователя или IP-адрес, но не хотите передавать их в каждый метод? Используйте MDC. // В фильтре на входе запроса MDC.put("userId", request.getHeader("X-User-ID")); // Где-то глубоко в сервисе log.info("Заказ создан"); // В JSON-логе автоматически появится поле "userId": "123" // В конце MDC.clear(); 🔥 Итог 1. Приложение пишет логи в JSON в консоль. 2. Filebeat забирает их и кидает в Elasticsearch. 3. Разработчик открывает Kibana и ищет проблему за 5 секунд по Trace ID. 4. Никаких SSH и grep. #DevOps #ELK #Logging #Kibana #Elasticsearch 👉 @BookJava

📊 Мониторинг: Пульс вашего приложения В мире мониторинга Java есть три главных игрока: 1. Spring Boot Actuator (Генерирует метрики). 2. Prometheus (Собирает и хранит их). 3. Grafana (Рисует красивые графики). Давайте разберем, как они работают вместе. 1️⃣ Spring Boot Actuator & Micrometer Сначала нужно научить приложение рассказывать о себе. В Spring Boot это делается добавлением двух зависимостей: Actuator и Micrometer. Micrometer это как SLF4J, только для метрик. Это фасад. Вы пишете код один раз, а Micrometer умеет отправлять эти данные хоть в Prometheus, хоть в Datadog, хоть в New Relic. В pom.xml: org.springframework.boot spring-boot-starter-actuator io.micrometer micrometer-registry-prometheus В application.yaml: management: endpoints: web: exposure: include: prometheus, health, info Теперь, если вы перейдете по адресу /actuator/prometheus, вы увидите не JSON, а скучный текст: # HELP jvm_memory_used_bytes The amount of used memory # TYPE jvm_memory_used_bytes gauge jvm_memory_used_bytes{area="heap",id="G1 Eden Space",} 2.5165824E7 http_server_requests_seconds_count{uri="/users",status="200",} 452.0 Это и есть пища для Прометея. 2️⃣ Prometheus: Пылесос данных Prometheus это Time Series Database (База данных временных рядов). Она хранит цифры с привязкой ко времени. Его киллер-фича: Pull Model (Модель вытягивания). В отличие от логов, которые приложение само отправляет (Push), Prometheus сам приходит к вашему приложению раз в 15 секунд и скачивает (Scrape) данные со страницы /actuator/prometheus. Почему Pull лучше Push? Если ваше приложение под дикой нагрузкой и умирает, оно не сможет отправить метрики. Но Prometheus придет, увидит, что ответа нет, и зафиксирует: "Сервис упал". 3️⃣ Grafana: Капитанский мостик Prometheus хранит данные, но смотреть на них в текстовом виде больно. Grafana подключается к Prometheus и превращает скучные цифры в космолет. Вы можете создать дашборды для всего: 🔴 JVM: Сколько памяти съедено? Как часто работает Garbage Collector? 🔴 Tomcat: Сколько потоков занято? 🔴 Бизнес-метрики: Сколько заказов оформлено за час? Какая выручка? Alerting (Оповещения): Самое важное - Графана умеет "кричать". Вы настраиваете правило: "Если количество ошибок 500 превышает 1% в течение 5 минут - отправь сообщение в Telegram/Slack команде дежурных". 🛠 Кастомные метрики Spring дает кучу метрик из коробки (CPU, Memory, HTTP requests). Но бизнесу нужны свои цифры. Создать их легко через MeterRegistry. @Service public class OrderService { private final Counter orderCounter; public OrderService(MeterRegistry registry) { // Создаем счетчик "orders.created" this.orderCounter = registry.counter("orders.created"); } public void createOrder(Order order) { repo.save(order); orderCounter.increment(); // +1 к метрике } } Теперь в Grafana вы увидите график "Заказов в секунду". 🔥 Итог 1. Actuator открывает "дверь" (/actuator/prometheus). 2. Prometheus заходит в эту дверь каждые 15 секунд и забирает цифры. 3. Grafana рисует графики на основе этих цифр и будит вас ночью, если всё сломалось. #DevOps #Monitoring #Prometheus #Grafana #SpringBoot 👉 @BookJava

☸️ Kubernetes: Оркестратор вашего зоопарка Представьте, что у вас 50 микросервисов, каждый запущен в 3 экземплярах (для надежности). Итого 150 контейнеров. Вдруг сервер №2 сгорает. 50 контейнеров умирают. Без K8s: Админ просыпается в 3 ночи и руками запускает их на сервере №3. С K8s: Вы спите. K8s замечает, что "кого-то не хватает", и сам перезапускает умершие контейнеры на живых серверах за секунды. Это называется Self-healing (Самовосстановление). Чтобы понять K8s, нужно выучить всего три главных слова: Pod, Deployment, Service. 📦 1. Pod - Атом системы В Docker мы запускаем Контейнеры. В Kubernetes мы запускаем Поды. • Pod - это минимальная единица. Это обертка вокруг одного (или нескольких) контейнеров. • У Пода есть свой IP-адрес. • Обычно: 1 Pod = 1 Контейнер с вашим app.jar. • Редко: 1 Pod = Java App + Sidecar (например, агент логирования). Они живут вместе, как сиамские близнецы, и делят сеть. 👮‍♂️ 2. Deployment (Развертывание) - Начальник Вы никогда не создаете Поды вручную. Потому что Поды смертны. Если Под умер - он умер. Вместо этого вы создаете Deployment. Это инструкция для K8s: "Я хочу, чтобы у меня ВСЕГДА было 3 копии моего приложения OrderService". Deployment создает ReplicaSet, который следит за численностью. • Если один Под упал K8s создает новый. • Если нагрузка выросла Вы меняете цифру 3 на 10, и K8s мгновенно создает еще 7 копий. 🚦 3. Service (Сервис) - Единая точка входа Поды рождаются и умирают. У них меняются IP-адреса. Как фронтенду узнать, на какой IP слать запрос, если они меняются каждую минуту? Тут выходит Service. Это стабильный сетевой адрес (и DNS-имя), который не меняется никогда. • Service работает как Load Balancer (Балансировщик). • Он принимает запрос на http://order-service и пересылает его на один из живых Подов. Ему все равно, 3 их или 30. 📝 Как это выглядит в коде? (YAML) В мире K8s мы не пишем команды, мы пишем Манифесты (YAML-файлы), описывающие Желаемое состояние. # 1. Описываем Deployment (Что запускать?) apiVersion: apps/v1 kind: Deployment metadata: name: my-java-app spec: replicas: 3 # Хочу 3 экземпляра! selector: matchLabels: app: backend template: metadata: labels: app: backend spec: containers: - name: java-app image: my-docker-hub/app:v1 # Берем этот образ ports: - containerPort: 8080 --- # 2. Описываем Service (Как достучаться?) apiVersion: v1 kind: Service metadata: name: my-backend-service spec: selector: app: backend # Ищи Поды с меткой 'backend' ports: - protocol: TCP port: 80 # Внешний порт targetPort: 8080 # Порт контейнера Вы скармливаете этот файл командой kubectl apply -f app.yaml, и магия случается. 🔥 Итог 1. Pod: Обертка над контейнером. 2. Deployment: Следит, чтобы нужное количество Подов всегда работало. 3. Service: Стабильный адрес, распределяющий запросы по Подам. #Kubernetes #K8s #DevOps #Docker #Java 👉 @BookJava

🚀 CI/CD: Роботы делают рутину за вас Аббревиатура состоит из двух частей, и они решают разные проблемы. 🛠 1. CI (Continuous Integration / Непрерывная интеграция) Суть: Разработчики постоянно (несколько раз в день) сливают свой код в общую ветку (например, main или develop). Каждый раз, когда вы делаете git push, специальный сервер (GitLab CI, GitHub Actions, Jenkins) автоматически: 1. Скачивает ваш свежий код. 2. Собирает проект (mvn clean compile). 3. Запускает все Unit и Integration тесты. Если хоть один тест упал - сборка помечается красным крестиком (Build Failed). Код не пройдет дальше. Итог: Ваша главная ветка в Git всегда находится в рабочем состоянии. 📦 2. CD (Continuous Delivery & Deployment) Здесь две буквы "D", и они немного отличаются: 🔴 Continuous Delivery (Доставка): Код автоматически собирается в готовый артефакт (например, Docker-образ) и кладется в хранилище. Нажать кнопку "Опубликовать на Production" должен человек (например, тимлид). 🔴 Continuous Deployment (Развертывание): Полная автоматизация. Прошли тесты? Собрался образ? Он сразу же автоматически загружается на боевой сервер и заменяет старую версию. (Так делает Amazon, выкатывая обновления тысячи раз в день). ⚙️ Анатомия Пайплайна (Pipeline) Пайплайн - это скрипт, состоящий из шагов (Stages), которые выполняются строго друг за другом. Упал предыдущий - следующий не запустится. Типичный пайплайн для Spring Boot + Docker: 1. Lint (Проверка стиля кода, нет ли неиспользуемых импортов). 2. Test (Запуск JUnit тестов). 3. Build (Сборка `app.jar`). 4. Dockerize (Сборка Docker-образа и отправка его в Docker Registry). 5. Deploy (Команда серверу: "Скачай новый образ и перезапустись"). 💻 Как это выглядит в коде? (GitHub Actions) Вам не нужно кликать мышкой в интерфейсах. Пайплайн описывается кодом (YAML) и лежит прямо в вашем репозитории (подход Infrastructure as Code). Вот пример простого .github/workflows/build.yml для Java-проекта: name: Spring Boot CI/CD on: push: branches: [ "main" ] # Запускать только при пуше в main jobs: build-and-test: runs-on: ubuntu-latest # Выделяем виртуальную машину Linux steps: - uses: actions/checkout@v3 # 1. Скачиваем код из Git - name: Установка Java 17 uses: actions/setup-java@v3 with: java-version: '17' distribution: 'temurin' - name: Сборка и Тесты (Maven) # 2. Запускаем тесты и сборку run: ./mvnw clean package # Дальше могут быть шаги для сборки Docker и деплоя... Стоит вам сделать git push, и GitHub сам поднимет сервер, выполнит эти команды и пришлет вам письмо, если что-то сломалось. 🆚 Что выбрать? 🔴 Jenkins: "Дед" в мире CI/CD. Мощный, гибкий, но сложный в настройке (нужно поднимать свой сервер). Написан на Java. 🔴 GitLab CI: Стандарт индустрии корпоративного сектора. Очень удобен, так как встроен прямо в репозиторий кода. 🔴 GitHub Actions: Современный, быстрый, идеален для Open Source и проектов, уже живущих в GitHub. 🔥 Итог CI/CD убивает фактор "человеческой ошибки". Вы перестаете бояться релизов. Деплой новой фичи превращается из стрессового события в пятницу вечером в скучную рутину: сделал пуш подождал 5 минут фича на проде. #DevOps #CICD #Java #SpringBoot #GitHubActions 👉 @BookJava

🧹 Гигиена кода: Рефакторинг и Технический долг Почему проекты умирают? Не из-за плохой идеи, а из-за того, что стоимость добавления новой фичи становится выше, чем прибыль от неё. Разработчики тратят 90% времени на чтение и распутывание старого кода, и только 10% - на написание нового. 💳 1. Technical Debt (Технический долг) Это метафора, придуманная Уордом Каннингемом. 🔴 Суть: Вы берете "кредит" у качества кода, чтобы выпустить фичу быстрее ("Сделаем костыль, потом поправим"). 🔴 Проценты: Каждая минута, потраченная на борьбу с этим костылем в будущем. 🔴 Банкротство: Момент, когда код настолько запутан, что проще всё переписать с нуля, чем добавить кнопку. Главное правило: Долги надо возвращать. Выделяйте 20% времени в спринте на рефакторинг. 2. Code Smells (Запахи кода) Как понять, что код "тухнет"? По запаху. Это не баги (код работает), это признаки плохого дизайна. Топ-5 самых вонючих мест: 1. God Object (Божественный объект): Класс Manager или Utils, который знает всё и делает всё. Нарушает SRP (Single Responsibility Principle). 2. Long Method (Длинный метод): Если метод не помещается на один экран монитора - это запах. 3. Magic Numbers (Магические числа): • Плохо: if (status == 7) ... (Что такое 7? Счастливое число?) • Хорошо: if (status == STATUS_ACTIVE) ... 4. Duplicated Code (Дублирование): Copy-Paste это зло. Если вы нашли ошибку в одном месте, вам придется искать её копии по всему проекту. Принцип DRY (Don't Repeat Yourself). 5. Feature Envy (Зависть к чужим данным): Метод класса А постоянно обращается к полям класса Б. Скорее всего, этот метод должен жить в классе Б. 🛠 3. Refactoring (Рефакторинг) Это процесс изменения структуры кода без изменения его поведения. Золотое правило Бойскаута: "Оставь место стоянки чище, чем оно было до твоего прихода." Зашли в файл поправить баг? Поправьте заодно название переменной или вынесите метод. Маленькие улучшения каждый день спасают проект. 💻 До и После 🤢 Было (Smelly Code): public void process(Order o) { // Magic Number + Long Method + Feature Envy if (o.getItems().size() > 0 && o.getStatus() == 1) { double total = 0; for (Item i : o.getItems()) { total += i.getPrice() * 1.2; // Что такое 1.2? НДС? Наценка? } System.out.println("Total: " + total); // Hardcoded output } } 😎 Стало (Clean Code): private static final double TAX_RATE = 1.2; private static final int STATUS_ACTIVE = 1; public void printOrderTotal(Order order) { if (isEligibleForProcessing(order)) { double total = calculateTotal(order); outputResult(total); } } private boolean isEligibleForProcessing(Order order) { return !order.isEmpty() && order.getStatus() == STATUS_ACTIVE; } private double calculateTotal(Order order) { return order.getItems().stream() .mapToDouble(item -> item.getPrice() * TAX_RATE) .sum(); } Код стал читаемым, как книга. 🔥 Итог 1. Технический долг неизбежен, но его нужно гасить. 2. Запахи кода (магические числа, дубликаты) подсказывают, где рефакторить. 3. Рефакторинг делаем только при наличии Тестов (иначе вы просто ломаете рабочий код). #Refactoring #CleanCode #TechnicalDebt #CodeSmells #Java 👉 @BookJava

🧠 Domain Driven Design: Программируем на языке бизнеса Главная проблема IT: Разработчики говорят на языке таблиц (INSERT, Foreign Key, DTO), а бизнес на языке денег и процессов («Провести проводку», «Списать остаток»). DDD (Предметно-ориентированное проектирование) - это попытка убрать переводчика. 🗣 1. Ubiquitous Language (Единый язык) Это фундамент. Код должен звучать так же, как речь эксперта. 🔴 Плохо (CRUD-мышление): • Бизнес: "Клиент сменил адрес доставки". • Код: user.setAddress("New York"); userRepo.save(user); 🔴 Хорошо (DDD): • Код: user.relocateTo(new Address("New York")); Методы должны называться глаголами бизнеса, а не сеттерами. 📦 2. Bounded Context (Ограниченный контекст) Самая большая ошибка новичка - создать один класс Product на всё приложение. 🔴 Для Продаж: Товар - это цена, описание, картинки. 🔴 Для Склада: Товар - это вес, габариты, номер полки. 🔴 Для Бухгалтерии: Товар - это актив, амортизация, инвентарный номер. В DDD мы не делаем монстра. Мы создаем разные модели для разных контекстов. 🔴 SalesContext.Product 🔴 WarehouseContext.StockItem Эти модели могут даже иметь разные ID и общаться друг с другом только через события (Kafka). 🏗 3. Tactical DDD (Строительные блоки) Как писать код внутри контекста? A. Entity (Сущность) Объект, у которого есть Identity (ID). Если у двух людей одинаковое имя, это все равно два разных человека (разные ID). 🔴 Пример: User, Order. 🔴 Они живут долго, меняют свое состояние, но остаются собой. B. Value Object (Объект-значение) Объект, который определяется только своими данными. У него нет ID. Он неизменяем (Immutable). 🔴 Пример: Money, Address, Color. 🔴 Если у меня есть 100 рублей и у вас 100 рублей - это одни и те же 100 рублей. Нам не важно, какая именно это купюра. 🔴 Правило: Не используйте примитивы! Вместо String email используйте класс EmailAddress. Там можно спрятать валидацию. C. Aggregate (Агрегат) Это кластер объектов, которые живут и умирают вместе. 🔴 Пример: Заказ (Order) + Позиции заказа (OrderItems). 🔴 Aggregate Root (Корень): Это главный объект (Order). 🔴 Правило: Извне можно обращаться только к Корню. Нельзя получить ссылку на OrderItem и изменить его цену напрямую. Вы должны сказать: order.changeItemPrice(...). Это гарантирует целостность данных. 🩸 Anemic vs Rich Model (Анемичная vs Богатая модель) ❌ Анемичная (Стандартный Spring): Класс — это просто мешок с геттерами и сеттерами. Вся логика лежит в Service. // Service public void completeOrder(Long id) { Order order = repo.findById(id); if (order.getStatus() != PAID) throw ... order.setStatus(COMPLETED); // Кто угодно может поменять статус! repo.save(order); } ✅ Богатая (DDD): Логика и валидация живут внутри Сущности. Сервис просто координирует работу. // Entity public void complete() { if (this.status != PAID) throw new DomainException("Не оплачено!"); this.status = COMPLETED; // Можно даже вернуть событие OrderCompletedEvent } // Service public void completeOrder(Long id) { Order order = repo.findById(id); order.complete(); // Вся бизнес-логика внутри repo.save(order); } 🔥 Итог DDD - это сложно, но необходимо для больших проектов. 1. Говорите на языке бизнеса (Ubiquitous Language). 2. Разделяйте модели (Bounded Contexts). 3. Используйте Value Objects вместо примитивов. 4. Прячьте логику внутрь Rich Domain Model. #Architecture #DDD #DomainDrivenDesign #Java #Microservices 👉 @BookJava