Библиотека Java разработчика

☸️ 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 📲 Мы в MAX 👉@BookJava

⚡️ Хотите освоить Backend-разработку с нуля, но не знаете, с чего начать? Java — это лучший старт! Курс «Java-разработчик» от OTUS — это 15 месяцев обучения, которое откроет вам двери в мир Java-разработки. Программа включает живые лекции от опытных наставников и актуальные инструменты, такие как IntelliJ IDEA, Spring, Hibernate, Docker и Kubernetes. Мы разбираем всё: от синтаксиса Java до создания серверных приложений и работы с базами данных. После курса вы сможете: ✔ создавать серверные приложения на Java; ✔ работать с реляционными и NoSQL базами данных; ✔ осваивать и применять фреймворки Spring, Hibernate, Docker, Kafka, RabbitMQ; ✔ претендовать на позицию Middle Java Developer в крупных компаниях. Оставьте заявку и получите скидку на большое обучение «Java-разработчик»: https://vk.cc/cUAK9u Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

🚀 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 📲 Мы в MAX 👉@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 📲 Мы в MAX 👉@BookJava

❗️Микросервисы часто обещают масштабируемость, но на практике превращаются в сложную и хрупкую систему. Причина почти всегда одна — неверная декомпозиция. Слишком мелкие сервисы, плотные связи, распределённые транзакции и постоянные проблемы с данными. На открытом уроке: - разберём, как правильно делить систему на сервисы - поговорим о границах микросервисов, ключевых шаблонах декомпозиции, подходах к взаимодействию и управлению согласованностью данных - вы увидите, как принимать архитектурные решения не по шаблону, а с учётом бизнес-контекста, нагрузки и эволюции системы - разберём типовые ошибки, из-за которых микросервисы теряют автономность и становятся сложнее монолита 📌 Встречаемся 18 февраля в преддверии старта курса «Highload Architect». Зарегистрируйтесь, чтобы не пропустить: https://vk.cc/cUudMf Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

🧠 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 📲 Мы в MAX 👉@BookJava

🧅 Архитектура: От Слоев к Луковице ❌ Проблема Слоенки (Database Driven Design) В классическом Spring-приложении зависимости идут сверху вниз: 1. Контроллер зависит от Сервиса. 2. Сервис зависит от Репозитория (Базы данных). В чем подвох? Ваша бизнес-логика (Сервис) намертво привязана к деталям хранения данных (БД). 🔴Хотите поменять SQL на NoSQL? Переписывайте сервис. 🔴Хотите протестировать логику? Придется мокать базу данных. 🔴Главный грех: База данных диктует, как писать бизнес-логику. А должно быть наоборот! ✅ Решение: Clean / Hexagonal / Onion Дядя Боб, Алистер Кокберн и другие умные дядьки придумали, как перевернуть игру. Главная идея: Зависимости должны быть направлены ТОЛЬКО внутрь, к центру. Представьте приложение как Луковицу. 1. Ядро (Core / Domain) - Центр Вселенной Здесь живет ваша Бизнес-логика. 🔴Сущности (User, Order). 🔴Правила (User не может быть моложе 18 лет). 🔴Правило: Здесь НЕТ фреймворков. Никакого Spring, никакого Hibernate, никакого SQL. Только чистая Java. 🔴Этот слой ничего не знает о внешнем мире. 2. Порты (Ports / Use Cases) - Граница Ядро определяет интерфейсы (Порты), которые ему нужны для работы. 🔴Например: interface UserRepository (найти пользователя, сохранить пользователя). 🔴Заметьте: интерфейс лежит внутри домена! 3. Адаптеры (Adapters / Infrastructure) - Внешний мир Здесь живут детали реализации. 🔴PostgresUserRepository реализует интерфейс UserRepository. 🔴RestController вызывает методы Ядра. 🔴Здесь подключается Spring, Hibernate, Kafka и всё остальное. 🔄 Инверсия Зависимостей (DIP) Следите за руками: 1. В слоеной архитектуре: Service зависит от PostgresDao. 2. В чистой архитектуре: Service зависит от Интерфейса. А PostgresDao зависит от Интерфейса. Оба зависят от абстракции. БД стала просто плагином. Вы можете выкинуть Postgres и поставить заглушку (In-Memory Map) - и бизнес-логика даже не заметит подмены! ⚖️ Когда что использовать? 1. Layered (Controller-Service-Repo) • ✅ Простые CRUD-приложения. • ✅ Админки, прототипы. • ✅ Когда логики почти нет, просто перекладываем данные. 2. Hexagonal (Ports & Adapters) • ✅ Сложная бизнес-логика (Банкинг, Финтех, Логистика). • ✅ Приложение живет долго (5+ лет). • ✅ Нужно писать много Unit-тестов для ядра, не поднимая контекст Spring. 🔥 Итог 🔴Layered: Быстро писать, сложно поддерживать. БД - главная. 🔴Clean: Дольше писать (много маппингов DTO <-> Entity), легко поддерживать. Логика - главная. #Architecture #CleanArchitecture #Hexagonal #Spring #Java 📲 Мы в MAX 👉@BookJava