Architecture with Spring: Hexagonal Architecture, Modular Monolith, CQRS, Event Sourcing, DDD mapping va package-by-domain enforcement mavzularidan iborat.

1. Architecture with Spring nima?

Architecture with Spring - Spring Boot yordamida application’ni shunchaki ishlaydigan qilib emas, balki:

• tushunarli

• test qilish oson

• o‘zgartirishga qulay

• biznesga mos

• katta jamoada boshqariladigan

• kelajakda bo‘linadigan

qilib loyihalashdir.

Oddiy developer savoli:

"Bu endpoint ishlaydimi?"

Arxitektor savoli:

"Bu tizim 2 yildan keyin ham oson o‘zgaradimi? Yangi modul qo‘shsak eski joylar buzilmaydimi? Biznes qoidalar framework’ga qaram bo‘lib qolmadimi?"

2. Oddiy layered architecture yetmay qoladigan joy

Junior/Middle bosqichida ko‘p ishlatiladigan tuzilma:

controller
service
repository
entity
dto

Masalan:

src/main/java/com/example/app
 ├── controller
 │    └── OrderController.java
 ├── service
 │    └── OrderService.java
 ├── repository
 │    └── OrderRepository.java
 ├── entity
 │    └── Order.java
 └── dto
      └── OrderRequest.java

Kichik project uchun yaxshi. Lekin katta project’da muammo chiqadi:

controller ichida hamma domainlar aralashadi
service ichida biznes logic ko‘payib ketadi
repository to‘g‘ridan-to‘g‘ri hamma joyga kiradi
entity biznes modeli o‘rniga database modeli bo‘lib qoladi
modullar orasida chegaralar yo‘qoladi

Natija:

Project ishlaydi, lekin o‘zgartirish xavfli bo‘ladi.

Arxitektor darajada maqsad - faqat qatlamlar emas, biznes chegaralarini ham to‘g‘ri ajratish.

3. Hexagonal Architecture in Spring Boot

Asosiy g‘oya

Hexagonal Architecture yoki Ports and Adapters Architecture shuni aytadi:

Biznes logic tashqi texnologiyalarga qaram bo‘lmasligi kerak.

Ya’ni biznes qoidalar:

• Spring MVC’ga qaram bo‘lmasin

• JPA’ga qaram bo‘lmasin

• Kafka’ga qaram bo‘lmasin

• Redis’ga qaram bo‘lmasin

• tashqi API’ga qaram bo‘lmasin

Spring, database, Kafka, REST API - bular adapter. Markazda esa domain turadi.

Oddiy ko‘rinish

                REST Controller
                      |
                      v
               Input Adapter
                      |
                      v
                Application Service
                      |
                      v
                   Domain
                      |
                      v
              Output Port Interface
                      |
                      v
              JPA / Kafka / External API Adapter

Package structure misol

com.company.order
 ├── domain
 │    ├── Order.java
 │    ├── OrderItem.java
 │    └── OrderStatus.java
 │
 ├── application
 │    ├── port
 │    │    ├── in
 │    │    │    └── CreateOrderUseCase.java
 │    │    └── out
 │    │         └── OrderRepositoryPort.java
 │    └── service
 │         └── CreateOrderService.java
 │
 ├── adapter
 │    ├── in
 │    │    └── web
 │    │         └── OrderController.java
 │    └── out
 │         └── persistence
 │              ├── JpaOrderRepository.java
 │              ├── SpringDataOrderRepository.java
 │              └── OrderEntity.java

Nima uchun bu yaxshi?

Chunki CreateOrderService database qanday ishlashini bilmaydi.

U faqat interface bilan ishlaydi:

public interface OrderRepositoryPort {
    Order save(Order order);
    Optional<Order> findById(OrderId id);
}

Service:

@Service
public class CreateOrderService implements CreateOrderUseCase {

    private final OrderRepositoryPort orderRepository;

    public CreateOrderService(OrderRepositoryPort orderRepository) {
        this.orderRepository = orderRepository;
    }

    @Override
    public Order create(CreateOrderCommand command) {
        Order order = Order.create(command.customerId(), command.items());
        return orderRepository.save(order);
    }
}

JPA adapter:

@Repository
public class JpaOrderRepository implements OrderRepositoryPort {

    private final SpringDataOrderRepository repository;

    public JpaOrderRepository(SpringDataOrderRepository repository) {
        this.repository = repository;
    }

    @Override
    public Order save(Order order) {
        OrderEntity entity = OrderMapper.toEntity(order);
        OrderEntity saved = repository.save(entity);
        return OrderMapper.toDomain(saved);
    }
}

Bu yerda muhim nuqta:

Domain va application service JPA’ni bilmaydi. JPA tashqi adapter.

4. Spring Boot’da Hexagonal Architecture qachon kerak?

Kerak bo‘ladi:

• biznes logic murakkab bo‘lsa

• project uzoq yashasa

• testability muhim bo‘lsa

• database keyin almashishi mumkin bo‘lsa

• tashqi integratsiyalar ko‘p bo‘lsa

• microservice darajasidagi service bo‘lsa

Kerak bo‘lmasligi mumkin:

• oddiy CRUD admin panel

• 5-10 ta endpointli kichik project

• tez MVP qilish kerak bo‘lsa

• biznes logic deyarli yo‘q bo‘lsa

Arxitektor qarori shunday bo‘ladi:

Har joyga Hexagonal tiqish shart emas. Lekin biznes logic muhim joyda juda foydali.

5. Modular Monolith with Spring Modulith

Modular Monolith nima?

Monolith degani bitta application. Lekin modular monolith degani:

Application bitta deploy bo‘ladi, lekin ichida aniq ajratilgan biznes modullar bo‘ladi.

Masalan marketplace:

marketplace-app
 ├── order
 ├── payment
 ├── delivery
 ├── user
 ├── notification
 └── catalog

Bu hali microservice emas. Hammasi bitta Spring Boot app ichida. Lekin har modul o‘z chegarasiga ega.

Oddiy monolith muammosi

OrderService -> PaymentRepository
PaymentService -> UserRepository
UserService -> OrderRepository
NotificationService -> hammasiga bog‘langan

Vaqt o‘tishi bilan:

hamma hammani chaqiradi
dependency tartibsiz bo‘ladi
o‘zgartirish xavfli bo‘ladi
microservice qilish juda qiyinlashadi

Modular monolith yondashuvi

order module faqat order logic’ni biladi
payment module faqat payment logic’ni biladi
delivery module faqat delivery logic’ni biladi

modullar bir-biri bilan to‘g‘ridan-to‘g‘ri ichki class orqali emas,
public API yoki event orqali gaplashadi

Spring Modulith nima beradi?

Spring Modulith quyidagilarga yordam beradi:

• application module chegaralarini tekshiradi

• module dependency’larini nazorat qiladi

• module integration test yozishga yordam beradi

• event-based communication’ni tartibga soladi

• modul strukturasini dokumentatsiya qilishga yordam beradi

Misol structure:

com.company.marketplace
 ├── order
 │    ├── OrderManagement.java
 │    ├── internal
 │    │    └── OrderService.java
 │    └── events
 │         └── OrderCreatedEvent.java
 │
 ├── payment
 │    ├── PaymentManagement.java
 │    └── internal
 │         └── PaymentService.java
 │
 └── delivery
      ├── DeliveryManagement.java
      └── internal
           └── DeliveryService.java

Bu yerda internal ichidagi classlarni boshqa module to‘g‘ridan-to‘g‘ri ishlatmasligi kerak.

6. CQRS implementation patterns in Spring

CQRS nima?

CQRS - Command Query Responsibility Segregation.

Ya’ni:

Ma’lumotni o‘zgartirish va ma’lumotni o‘qish alohida model bilan ishlaydi.

Oddiy CRUD’da:

OrderService
 ├── createOrder()
 ├── updateOrder()
 ├── cancelOrder()
 ├── getOrder()
 └── listOrders()

CQRS’da:

Command side:
 ├── CreateOrderCommandHandler
 ├── CancelOrderCommandHandler
 └── PayOrderCommandHandler

Query side:
 ├── GetOrderQueryHandler
 └── SearchOrdersQueryHandler

Nima uchun CQRS kerak?

Chunki write va read ehtiyojlari har xil bo‘ladi.

Masalan:

Write side

Buyurtma yaratish
Payment tekshirish
Stock kamaytirish
Domain validation
Transaction
Event chiqarish

Read side

Buyurtmalar ro‘yxati
Filter
Search
Pagination
Projection
Dashboard uchun tez o‘qish

Bitta model bilan ikkalasini qilish ba’zida projectni og‘irlashtiradi.

Spring Boot’da oddiy CQRS misol

order
 ├── command
 │    ├── CreateOrderCommand.java
 │    ├── CreateOrderHandler.java
 │    └── CancelOrderHandler.java
 │
 ├── query
 │    ├── GetOrderQuery.java
 │    ├── GetOrderHandler.java
 │    └── OrderViewRepository.java
 │
 └── domain
      └── Order.java

Command:

public record CreateOrderCommand(
        Long customerId,
        List<Long> productIds
) {}

Handler:

@Service
public class CreateOrderHandler {

    private final OrderRepositoryPort orderRepository;

    public CreateOrderHandler(OrderRepositoryPort orderRepository) {
        this.orderRepository = orderRepository;
    }

    @Transactional
    public Long handle(CreateOrderCommand command) {
        Order order = Order.create(command.customerId(), command.productIds());
        orderRepository.save(order);
        return order.getId();
    }
}

Query:

@Service
public class GetOrderHandler {

    private final OrderViewRepository repository;

    public GetOrderHandler(OrderViewRepository repository) {
        this.repository = repository;
    }

    public OrderView handle(Long orderId) {
        return repository.findViewById(orderId)
                .orElseThrow(() -> new OrderNotFoundException(orderId));
    }
}

CQRS har doim kerakmi?

Yo‘q.

CQRS foydali bo‘ladi:

• read/write logic juda farq qilsa

• reporting ko‘p bo‘lsa

• dashboard og‘ir bo‘lsa

• event-driven system bo‘lsa

• write model murakkab domain bo‘lsa

Kerak emas:

• oddiy CRUD

• kichik admin panel

• kam endpointli service

• jamoa tajribasi yetarli bo‘lmasa

7. Event Sourcing with Spring & Axon Framework

Event Sourcing nima?

Oddiy tizimda database’da oxirgi holat saqlanadi:

orders table:
id = 1
status = PAID
total = 300000

Event sourcing’da esa holat emas, voqealar tarixi saqlanadi:

OrderCreated
OrderItemAdded
PaymentStarted
PaymentCompleted
OrderConfirmed

Order’ning hozirgi holati shu eventlardan qayta tiklanadi.

Oddiy holat vs Event Sourcing

Oddiy state-based model

Order status = DELIVERED

Lekin savol:

Qachon yaratildi?
Kim to‘ladi?
Qachon status o‘zgardi?
Nega cancel bo‘lmadi?

Bular uchun alohida audit kerak bo‘ladi.

Event Sourcing

1. OrderCreated
2. PaymentCompleted
3. DeliveryStarted
4. OrderDelivered

Tarixning o‘zi asosiy ma’lumot bo‘ladi.

Qachon Event Sourcing kerak?

Kerak bo‘ladi:

• audit juda muhim bo‘lsa

• moliya/payment tizimlari

• banking

• order lifecycle murakkab bo‘lsa

• voqealar tarixi biznes uchun qimmatli bo‘lsa

• state’ni qayta tiklash kerak bo‘lsa

Kerak bo‘lmasligi mumkin:

• oddiy CRUD

• report-only tizim

• kichik project

• jamoa event sourcing tajribasiga ega bo‘lmasa

Axon Framework nima qiladi?

Axon Framework Java/Spring ekotizimida:

• command handling

• event publishing

• event store

• aggregate

• saga

• CQRS

• event sourcing

kabi narsalarni tartibli qilishga yordam beradi.

Lekin Arxitektor qaror:

Axon kuchli, lekin murakkab. Uni faqat haqiqiy ehtiyoj bo‘lsa tanlash kerak.

8. DDD mapping to Spring layers

DDD nima?

DDD - Domain-Driven Design.

Asosiy g‘oya:

Kod strukturasi biznes tiliga mos bo‘lishi kerak.

Masalan, e-commerce’da biznes so‘zlari:

Order
Payment
Customer
Product
Cart
Delivery
Invoice
Refund

Kod ham shularga qarab tuzilishi kerak.

Noto‘g‘ri yondashuv

controller
service
repository
entity
dto

Bu texnik qatlamlarga qarab bo‘lingan. Katta project’da biznes context yo‘qoladi.

Yaxshiroq yondashuv: package-by-domain

com.company.marketplace
 ├── order
 │    ├── domain
 │    ├── application
 │    ├── adapter
 │    └── api
 │
 ├── payment
 │    ├── domain
 │    ├── application
 │    ├── adapter
 │    └── api
 │
 └── delivery
      ├── domain
      ├── application
      ├── adapter
      └── api

Bu yerda project biznes bo‘yicha o‘qiladi.

DDD elementlari

Entity

Identity bor obyekt.

public class Order {
    private OrderId id;
    private CustomerId customerId;
    private OrderStatus status;
}

Value Object

Identity yo‘q, qiymati bilan teng.

public record Money(BigDecimal amount, String currency) {}

Aggregate

Bir nechta entity/value object’larni boshqaradigan domain chegarasi.

public class Order {
    private List<OrderItem> items;

    public void addItem(Product product, int quantity) {
        // business rule here
    }

    public void confirm() {
        if (items.isEmpty()) {
            throw new OrderCannotBeConfirmedException();
        }
        this.status = OrderStatus.CONFIRMED;
    }
}

Repository

Domain obyektni saqlash interface’i.

public interface OrderRepository {
    Order save(Order order);
    Optional<Order> findById(OrderId id);
}

Muhim:

DDD’da repository database table uchun emas, aggregate uchun ishlaydi.

9. Package-by-domain enforcement

Muammo

Developerlar vaqt o‘tib qoidani buzadi:

payment.internal.PaymentService

ni order module ichidan chaqirib yuboradi.

Yoki:

order.repository.OrderRepository

ni boshqa module ishlatib yuboradi.

Natija:

module boundary buziladi
tight coupling paydo bo‘ladi
microservice qilish qiyinlashadi
testlar murakkablashadi

Buni qanday nazorat qilamiz?

1. Package convention

order.internal faqat order ichida ishlatiladi
order.api boshqa module uchun public contract

2. ArchUnit tests

ArchUnit bilan architecture qoidalarini test qilamiz.

Misol:

@AnalyzeClasses(packages = "com.company.marketplace")
public class ArchitectureTest {

    @ArchTest
    static final ArchRule order_should_not_access_payment_internal =
            noClasses()
                    .that().resideInAPackage("..order..")
                    .should().accessClassesThat()
                    .resideInAPackage("..payment.internal..");
}

Bu test nima qiladi?

order module payment.internal ichidagi classlarni ishlatsa, test yiqiladi.

Bu Arxitektor darajasida juda muhim.

10. Architecture with Spring uchun ideal structure

Katta, biznes logic ko‘p project uchun yaxshi structure:

com.company.marketplace
 ├── order
 │    ├── api
 │    │    ├── OrderFacade.java
 │    │    └── OrderCreatedEvent.java
 │    │
 │    ├── application
 │    │    ├── command
 │    │    ├── query
 │    │    └── service
 │    │
 │    ├── domain
 │    │    ├── Order.java
 │    │    ├── OrderItem.java
 │    │    ├── OrderStatus.java
 │    │    └── OrderRepository.java
 │    │
 │    ├── adapter
 │    │    ├── in
 │    │    │    └── web
 │    │    └── out
 │    │         ├── persistence
 │    │         └── messaging
 │    │
 │    └── internal
 │         └── OrderInternalService.java
 │
 ├── payment
 ├── delivery
 └── notification

Bu structure’da:

11. Arxitektor qanday qaror qiladi?

Arxitektor har doim pattern tanlashdan oldin savol beradi:

1. Biznes murakkabmi?

Agar faqat CRUD bo‘lsa:

Controller → Service → Repository

yetadi.

Agar domain murakkab bo‘lsa:

Hexagonal + DDD

yaxshi.

2. System kelajakda bo‘linadimi?

Agar kelajakda microservice qilish ehtimoli bo‘lsa:

Modular Monolith + Spring Modulith

juda yaxshi start.

3. Read/write load farq qiladimi?

Agar read juda ko‘p, write murakkab bo‘lsa:

CQRS

ko‘rib chiqiladi.

4. Audit va tarix muhimmi?

Agar har bir o‘zgarish tarixi muhim bo‘lsa:

Event Sourcing

ko‘rib chiqiladi.

5. Team buni ko‘tara oladimi?

Eng muhim savol:

Pattern chiroyli, lekin jamoa tushunmasa project battar murakkablashadi.

Arxitektor faqat texnik emas, jamoa darajasini ham hisobga oladi.

12. Real hayotiy misol: Online Shop

Oddiy variant:

OrderController
OrderService
OrderRepository
PaymentService
DeliveryService

Tez yoziladi, lekin katta bo‘lsa chalkashadi.

Arxitektor varianti:

order module
 ├── CreateOrderUseCase
 ├── Order aggregate
 ├── OrderRepositoryPort
 ├── JpaOrderAdapter
 └── OrderCreatedEvent

payment module
 ├── PaymentFacade
 ├── Payment aggregate
 └── PaymentCompletedEvent

delivery module
 ├── DeliveryFacade
 └── DeliveryStartedEvent

Flow:

1. User order yaratadi
2. Order module OrderCreatedEvent chiqaradi
3. Payment module eventni eshitadi
4. Payment tugasa PaymentCompletedEvent chiqadi
5. Delivery module delivery boshlaydi

Bu yondashuvda modullar kuchli ajratilgan bo‘ladi.

13. Eng ko‘p qilinadigan xatolar

Xato 1: Har joyga Hexagonal Architecture ishlatish

Kichik CRUD project’da bu ortiqcha bo‘lishi mumkin.

Xato 2: Domain modelni JPA entity bilan aralashtirish

Ba’zida mumkin, lekin murakkab domain’da yaxshi emas.

@Entity
public class Order {
    // biznes logic + JPA annotation + relation + serialization
}

Bu class haddan tashqari ko‘p mas’uliyat oladi.

Xato 3: Service classni "God Service" qilish

OrderService
 ├── createOrder()
 ├── payOrder()
 ├── deliverOrder()
 ├── refundOrder()
 ├── sendNotification()
 ├── updateStock()
 └── generateInvoice()

Bu yomon signal.

Yaxshiroq:

CreateOrderHandler
PayOrderHandler
CancelOrderHandler
RefundOrderHandler

Xato 4: Modullar orasida ichki classlarni chaqirish

order -> payment.internal.PaymentService

Bu boundary buzadi.

Yaxshiroq:

order -> payment.api.PaymentFacade

yoki event orqali:

OrderCreatedEvent -> Payment module

Xato 5: Patternni biznes ehtiyojsiz tanlash

CQRS, Event Sourcing, Hexagonal, DDD - bular kuchli. Lekin noto‘g‘ri joyda ishlatilsa projectni og‘irlashtiradi.

14. Qisqa qoida

Arxitektor darajada Spring architecture uchun asosiy qoida:

Business logic framework’dan mustaqil bo‘lsin.
Modullar chegarasi aniq bo‘lsin.
Ichki classlar tashqariga sizib chiqmasin.
Read va write murakkab bo‘lsa ajratilsin.
Architecture test bilan nazorat qilinsin.

15. Amaliy mini roadmap

Bu mavzuni o‘rganishdagi ketma-ketlik:

1. Layered Architecture'ni yaxshi tushunish

2. Package-by-feature / package-by-domain qilish

3. DDD basics: Entity, Value Object, Aggregate, Repository

4. Hexagonal Architecture: port va adapter

5. Modular Monolith: module boundary

6. Spring Modulith bilan module tekshirish

7. CQRS: command/query ajratish

8. Event Sourcing: faqat kerak bo‘lsa

9. ArchUnit bilan architecture qoidalarini test qilish

Xulosa

Architecture with Spring - bu Spring Boot project’ni professional, uzoq yashaydigan va oson kengayadigan qilib qurish san’ati.

Boshlang'ich Spring’da endpoint yozadi.
Junior layer ajratadi.
Middle transaction, security, caching, testingni chuqur biladi.
Senior performance va distributed system bilan ishlaydi.
Arxitektor esa quyidagini hal qiladi:

"Bu tizimning chegaralari qayerda? Qaysi module nima uchun javobgar? Framework biznes logicni bosib ketmadimi? 2 yildan keyin bu projectni bo‘lish, kengaytirish, test qilish mumkinmi?"

Ya’ni har bir team quyidagilarni o‘zi boshidan o‘ylab chiqmaydi:

Logging qanday bo‘ladi?
Security qanday qo‘shiladi?
Tracing qanday ishlaydi?
Exception response formati qanday?
Dependency versionlarni kim boshqaradi?
Project structure qanday bo‘ladi?
Actuator, metrics, health check doim bormi?

Arxitektor darajasida maqsad:

Har bir yangi Spring Boot service bir xil sifat, bir xil structure, bir xil observability, bir xil security va bir xil dependency boshqaruvi bilan boshlansin.

Platform Standardization maqolasi quyidagi qismlardan iborat: internal Spring Boot starter library, centralized security configuration starter, shared observability setup, BOM, project template strategy, va ArchUnit bilan convention enforcement.

1. Nega Platform Standardization kerak?

Katta kompaniyada 10 ta Spring Boot service bo‘lsa, odatda bunday muammo chiqadi:

user-service      → Spring Boot 3.2
payment-service   → Spring Boot 3.1
order-service     → log format boshqa
delivery-service  → security config boshqa
billing-service   → actuator yopiq
catalog-service   → tracing yo‘q
notification      → exception response boshqa

Boshida bu kichik muammo ko‘rinadi. Lekin production’da katta og‘riq beradi:

• loglarni qidirish qiyinlashadi

• security xatolar ko‘payadi

• dependency conflict chiqadi

• monitoring bir xil bo‘lmaydi

• yangi service yaratish sekinlashadi

• har team bir xil muammoni qayta yechadi

• incident vaqtida tizimni tushunish qiyinlashadi

Platform standardization shuni hal qiladi:

Har service bir xil asosdan boshlanadi.
Har service minimal production talablariga javob beradi.
Har team infrastructure detallarini qayta yozmaydi.

2. Platform team nima qiladi?

Platform team yoki architect team odatda quyidagilarni beradi:

company-spring-boot-starter
company-security-starter
company-observability-starter
company-error-handling-starter
company-bom
company-project-template
architecture-tests
coding conventions

Bu narsalar product teamlarga tayyor beriladi.

Product developer shunchaki dependency qo‘shadi:

<dependency>
    <groupId>com.company.platform</groupId>
    <artifactId>company-web-starter</artifactId>
</dependency>

Va avtomatik keladi:

standard logging
standard error format
standard security headers
standard actuator config
standard tracing
standard metrics
standard correlation-id
standard OpenAPI config

3. Internal Spring Boot Starter Library

Starter nima?

Spring Boot starter - bu bir nechta dependency va configuration’ni bitta package qilib berish usuli.

Spring Boot rasmiy hujjatlarida auto-configuration jar dependency’lar asosida application’ni avtomatik sozlashga harakat qilishi aytiladi. Masalan, classpath’da kerakli kutubxona bo‘lsa va user o‘zi bean bermagan bo‘lsa, Spring Boot kerakli bean’ni auto-config qiladi. (Home)

Custom starter esa kompaniya ichida shunday ishlaydi:

company-security-starter qo‘shildi
        ↓
SecurityFilterChain avtomatik sozlandi
        ↓
JWT decoder avtomatik ulandi
        ↓
public endpointlar standart bo‘ldi
        ↓
security headers qo‘shildi

Spring Boot rasmiy hujjatlarida custom auto-configuration odatda starter bilan bog‘lanishi, starter esa auto-configuration code va kerakli kutubxonalarni birga berishi tushuntirilgan. (Home)

Nega internal starter kerak?

Chunki har projectda shu kodni qayta yozish xato:

@Configuration
public class SecurityConfig {
    // 150 qator security sozlama
}

@Configuration
public class ObservabilityConfig {
    // tracing, metrics, MDC
}

@ControllerAdvice
public class GlobalExceptionHandler {
    // standard error response
}

Yaxshiroq:

<dependency>
    <groupId>com.company.platform</groupId>
    <artifactId>company-service-starter</artifactId>
</dependency>

Va common konfiguratsiya avtomatik ulanadi.

4. Internal starter structure

Masalan:

company-platform
 ├── company-web-starter
 ├── company-security-starter
 ├── company-observability-starter
 ├── company-exception-starter
 ├── company-data-starter
 └── company-bom

Har starter alohida mas’uliyatga ega.

5. Starter ichida auto-configuration

Spring Boot 3.x’da custom auto-configuration odatda shunday yoziladi:

package com.company.platform.web;

import org.springframework.boot.autoconfigure.AutoConfiguration;
import org.springframework.context.annotation.Bean;

@AutoConfiguration
public class CompanyWebAutoConfiguration {

    @Bean
    public CorrelationIdFilter correlationIdFilter() {
        return new CorrelationIdFilter();
    }
}

Keyin AutoConfiguration.imports faylida ro‘yxatdan o‘tkaziladi:

META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports

Ichida:

com.company.platform.web.CompanyWebAutoConfiguration

Shunda starter dependency sifatida qo‘shilganda Spring Boot uni avtomatik ko‘radi.

6. @ConditionalOnMissingBean

Internal starter majburlab emas, default berib ishlashi kerak.

Yomon:

@Bean
public ObjectMapper objectMapper() {
    return new ObjectMapper();
}

Bu product team custom ObjectMapper bermoqchi bo‘lsa conflict qiladi.

Yaxshi:

@Bean
@ConditionalOnMissingBean
public ObjectMapper objectMapper() {
    return new ObjectMapper()
            .findAndRegisterModules();
}

Bu nimani anglatadi?

Agar application o‘z ObjectMapper bean’ini bermagan bo‘lsa,
platform default ObjectMapper beradi.
Agar application o‘zi bergan bo‘lsa,
platform aralashmaydi.

Arxitektor qoida:

Platform default beradi, lekin product teamga override imkonini qoldiradi.

7. Centralized Security Configuration Starter

Security har service’da boshqacha yozilsa, xavf oshadi.

Masalan, bitta service’da:

.requestMatchers("/actuator/**").permitAll()

boshqasida:

.anyRequest().permitAll()

boshqasida CSRF noto‘g‘ri disable qilingan.

Bunday holatda production’da security incident bo‘lishi oson.

company-security-starter

Bu starter quyidagilarni standart qiladi:

JWT validation
OAuth2 Resource Server config
public endpoint convention
role/scope mapping
security headers
CORS policy
actuator endpoint security
method security
audit logging

Misol:

@AutoConfiguration
@EnableMethodSecurity
public class CompanySecurityAutoConfiguration {

    @Bean
    @ConditionalOnMissingBean
    SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        return http
                .authorizeHttpRequests(auth -> auth
                        .requestMatchers("/actuator/health", "/actuator/info").permitAll()
                        .requestMatchers("/api/public/**").permitAll()
                        .anyRequest().authenticated()
                )
                .oauth2ResourceServer(oauth -> oauth.jwt())
                .build();
    }
}

Bu bilan har service default secure bo‘ladi.

Security starter’da ehtiyot bo‘lish kerak

Platform security starter haddan tashqari qattiq bo‘lsa, teamlar uni chetlab o‘tadi.

Yaxshi starter:

secure default beradi
override qilishga ruxsat beradi
config property orqali sozlanadi
documentation bor
test utilities beradi

Masalan:

company:
  security:
    public-paths:
      - /api/public/**
      - /swagger-ui/**
    required-scope: orders.read

8. Shared Observability Setup

Observability - production’da systemni ko‘ra olish:

logs
metrics
traces
health checks
alerts
correlation-id

Har service’da observability bir xil bo‘lishi kerak.

company-observability-starter

Bu starter quyidagilarni beradi:

Actuator endpoints
Micrometer metrics
Prometheus registry
traceId/spanId logging
correlation-id filter
structured logging
custom business metrics
health indicators

Misol:

Request keldi
        ↓
CorrelationIdFilter correlation-id yaratdi
        ↓
MDC ichiga qo‘ydi
        ↓
Loglarda correlationId chiqdi
        ↓
Trace systemga yuborildi
        ↓
Prometheus metrics yig‘di

Log formati hamma service’da bir xil bo‘lsa, incident vaqtida juda katta foyda beradi.

Standard log format

Masalan:

{
  "timestamp": "2026-05-21T10:15:00Z",
  "level": "INFO",
  "service": "order-service",
  "traceId": "abc123",
  "spanId": "def456",
  "correlationId": "req-789",
  "message": "Order created"
}

Bu format har service’da bir xil bo‘lsa:

Kibana / Grafana Loki / Datadog’da qidirish oson bo‘ladi.
Trace bilan log bog‘lanadi.
Incident debugging tezlashadi.

9. Standard Error Handling Starter

Har service xatoni har xil qaytarsa, frontend va boshqa service’lar qiynaladi.

Yomon:

{
  "error": "Bad request"
}

Boshqa service:

{
  "message": "Validation failed",
  "code": 400
}

Boshqa service:

{
  "timestamp": "...",
  "status": 400,
  "path": "/orders"
}

Yaxshi standart:

{
  "type": "VALIDATION_ERROR",
  "message": "Validation failed",
  "traceId": "abc123",
  "details": [
    {
      "field": "email",
      "message": "must be a valid email"
    }
  ]
}

Global exception starter

@RestControllerAdvice
public class CompanyExceptionHandler {

    @ExceptionHandler(ValidationException.class)
    public ResponseEntity<ApiError> handleValidation(ValidationException ex) {
        return ResponseEntity.badRequest().body(
                ApiError.validation(ex.getMessage())
        );
    }

    @ExceptionHandler(EntityNotFoundException.class)
    public ResponseEntity<ApiError> handleNotFound(EntityNotFoundException ex) {
        return ResponseEntity.status(HttpStatus.NOT_FOUND).body(
                ApiError.notFound(ex.getMessage())
        );
    }
}

Buni har service’da qayta yozish kerak emas. Starter beradi.

10. BOM - Bill of Materials

BOM nima?

BOM - dependency versionlarni markazdan boshqarish.

Masalan, har project o‘zi yozsa:

<spring.boot.version>3.3.1</spring.boot.version>
<spring.cloud.version>2023.0.2</spring.cloud.version>
<mapstruct.version>1.5.5</mapstruct.version>
<testcontainers.version>1.19.8</testcontainers.version>

Bitta projectda boshqa, ikkinchisida boshqa bo‘lib ketadi.

BOM bilan:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.company.platform</groupId>
            <artifactId>company-bom</artifactId>
            <version>1.4.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Keyin dependency version yozilmaydi:

<dependency>
    <groupId>org.testcontainers</groupId>
    <artifactId>postgresql</artifactId>
</dependency>

Spring Boot Gradle plugin hujjatlarida dependency’larni boshqarish uchun io.spring.dependency-management plugin yoki Gradle native BOM support ishlatilishi mumkinligi aytilgan. (Home) Gradle rasmiy hujjatlarida BOM dependency version constraints’larni markaziy boshqarish uchun ishlatilishi ko‘rsatilgan. (Gradle Documentation)

Company BOM ichida nima bo‘ladi?

Spring Boot version
Spring Cloud version
Spring Modulith version
MapStruct version
Testcontainers version
OpenAPI version
Micrometer version
Resilience4j version
Kafka client version
PostgreSQL driver version

Foydasi:

dependency conflict kamayadi
upgrade markazdan qilinadi
CVE patch qilish osonlashadi
teamlar version tanlashga vaqt sarflamaydi
build reproducible bo‘ladi

11. Project Template Strategy

Har yangi service noldan yaratilmasligi kerak.

Yomon:

Developer start.spring.io ga kiradi
dependencylarni taxminan tanlaydi
package structure o‘zi qiladi
security keyin qo‘shiladi
observability esdan chiqadi

Yaxshi:

company project template ishlatiladi
default package structure bor
starterlar tayyor
CI/CD pipeline bor
Dockerfile bor
Actuator bor
test skeleton bor
README bor

Spring Initializr rasmiy hujjatlarida o‘z custom Initializr instance’ingizni yaratish, dependencylar ro‘yxati va project attribute constraints’larni sozlash mumkinligi aytilgan. (Home)

Template ichida nima bo‘lishi kerak?

src/main/java/com/company/service
 ├── ServiceApplication.java
 ├── config
 ├── common
 ├── module1
 └── module2

src/test/java
 ├── ArchitectureTest.java
 ├── IntegrationTestBase.java
 └── TestcontainersConfig.java

Dockerfile
docker-compose.yml
README.md
openapi.yml
.github/workflows/build.yml yoki .gitlab-ci.yml

Minimum production template:

Health check
Readiness/liveness
Structured logging
Security default
Exception format
OpenAPI config
Testcontainers setup
Architecture test
Docker build
CI quality gates

12. Archetype yoki Custom Initializr?

Maven Archetype

Oddiy project skeleton yaratish uchun ishlatiladi.

Foydasi:

sodda
tez
ichki template uchun yetarli

Kamchiligi:

dynamic dependency tanlash qiyinroq
UI yo‘q
enterprise customization cheklangan

Custom Spring Initializr

Katta platform uchun kuchliroq.

Foydasi:

ichki start.company.com qilish mumkin
team dependency tanlaydi
Java version constraint beriladi
Spring Boot version nazorat qilinadi
company starterlar default chiqadi

Masalan:

start.company.uz
 ├── Web API Service
 ├── Kafka Consumer Service
 ├── Batch Job
 ├── Modulith Application
 └── Library Project

Arxitektor qaror:

Kichik kompaniyada template yetadi. Katta kompaniyada custom Initializr yoki internal developer portal foydaliroq.

13. Enforcing Conventions - ArchUnit Tests

Documentation yetarli emas. Qoidalar test bilan tekshirilishi kerak.

ArchUnit user guide’da architecture qoidalarini concise syntax bilan yozish va layered architecture kabi tayyor qoidalar mavjudligi ko‘rsatilgan. (ArchUnit)

Misol: Controller repository chaqirmasin

@AnalyzeClasses(packages = "com.company")
class ArchitectureTest {

    @ArchTest
    static final ArchRule controllers_should_not_access_repositories =
            noClasses()
                    .that().resideInAPackage("..controller..")
                    .should().accessClassesThat()
                    .resideInAPackage("..repository..");
}

Bu nimani himoya qiladi?

Controller → Service → Repository tartibini

Misol: internal package tashqaridan ishlatilmasin

@ArchTest
static final ArchRule internal_packages_should_not_be_accessed =
        noClasses()
                .that().resideOutsideOfPackage("..order..")
                .should().accessClassesThat()
                .resideInAPackage("..order.internal..");

Bu modular architecture’ni himoya qiladi.

Misol: Service classlar @Transactional bilan ishlasin

@ArchTest
static final ArchRule services_should_be_transactional =
        classes()
                .that().resideInAPackage("..application..")
                .and().haveSimpleNameEndingWith("Service")
                .should().beAnnotatedWith(Transactional.class);

Ehtiyot bo‘lish kerak: bunday qoida hamma project uchun mos bo‘lmasligi mumkin. Shuning uchun platform convention aniq yozilishi kerak.

14. Standard Package Structure

Platform team quyidagi structure’ni majburlashi mumkin:

com.company.<service>
 ├── <domain-module>
 │    ├── api
 │    ├── application
 │    ├── domain
 │    ├── adapter
 │    │    ├── in
 │    │    │    └── web
 │    │    └── out
 │    │         ├── persistence
 │    │         └── messaging
 │    └── internal
 │
 ├── config
 └── ServiceApplication.java

Yoki sodda service uchun:

com.company.<service>
 ├── controller
 ├── service
 ├── repository
 ├── dto
 ├── config
 └── exception

Arxitektor muhim qaror qiladi:

Hamma service’ga bir xil murakkab architecture tiqilmaydi. Service turiga qarab template bo‘ladi.

15. Service Type bo‘yicha standartlar

Bu juda muhim. Chunki platform standardization degani bitta qolipni hammaga majburlash emas.

16. Versioning Strategy

Platform starterlar ham versionlanadi.

Masalan:

company-platform-bom: 1.0.0
company-platform-bom: 1.1.0
company-platform-bom: 2.0.0

Semantic versioning:

PATCH 1.0.1 → bug fix
MINOR 1.1.0 → backward compatible feature
MAJOR 2.0.0 → breaking change

Product service company-bom versionini yangilaydi:

<company.platform.version>1.4.0</company.platform.version>

Va barcha common dependencylar boshqariladi.

17. Platform upgrade process

Yaxshi platform team shunday ishlaydi:

1. Yangi Spring Boot version chiqadi
2. Platform team compatibility tekshiradi
3. company-bom update qilinadi
4. starterlar test qilinadi
5. migration guide yoziladi
6. sample service yangilanadi
7. product teamlarga upgrade PR ochiladi

Bu Spring Boot upgrade’ni har team alohida boshdan o‘tkazmasligini ta’minlaydi.

18. Security patch va CVE boshqaruvi

Agar har service dependency versionni o‘zi boshqarsa:

Log4j / Netty / Jackson / Tomcat CVE chiqsa,
qaysi service qaysi versionda ekanini topish qiyin.

BOM bilan:

company-bom update qilinadi
barcha service bir xil patched versionga o‘tadi
CI tekshiradi

Platform standardization production xavfsizlik uchun ham kerak.

19. Developer Experience - DX

Platform standardization faqat control emas. Developer hayotini osonlashtirishi kerak.

Yomon platform:

ko‘p qoida
kam dokumentatsiya
override qiyin
starterlar magic qiladi
xato chiqqanda tushunarsiz

Yaxshi platform:

tez project yaratadi
defaultlar xavfsiz
documentation aniq
sample project bor
starterlar override bo‘ladi
error message tushunarli
migration guide bor

Arxitektor uchun muhim savol:

Platform team product teamlarga yordam beryaptimi yoki faqat cheklov qo‘yyaptimi?

20. Real kompaniya misoli

Tasavvur qilamiz, sizda 20 ta Spring Boot service bor.

Platform standardization oldin:

Har service boshqa log format.
Security config har xil.
Exception response har xil.
Actuator ba’zilarida ochiq, ba’zilarida yopiq.
Dependency versionlar chalkash.
Yangi service yaratish 2-3 kun.

Platform standardization keyin:

Yangi service 15 daqiqada template’dan yaratiladi.
Security default tayyor.
Observability default tayyor.
Error response bir xil.
Dependencylar BOM orqali boshqariladi.
Architecture testlar bor.
CI pipeline standart.

Bu Arxitektor darajasidagi katta yutuq.

21. Minimal platform starter misoli

Auto-configuration

@AutoConfiguration
@EnableConfigurationProperties(CompanyProperties.class)
public class CompanyPlatformAutoConfiguration {

    @Bean
    @ConditionalOnMissingBean
    public CorrelationIdFilter correlationIdFilter() {
        return new CorrelationIdFilter();
    }

    @Bean
    @ConditionalOnMissingBean
    public ApiErrorFactory apiErrorFactory() {
        return new ApiErrorFactory();
    }
}

Properties

@ConfigurationProperties(prefix = "company.platform")
public record CompanyProperties(
        boolean correlationIdEnabled,
        String serviceName
) {}

application.yml

company:
  platform:
    correlation-id-enabled: true
    service-name: order-service

Bu starter barcha service’larda bir xil correlation-id va error handling beradi.

22. Platform standardization’da nimalarni majburlash kerak?

Majburiy bo‘lishi kerak

dependency BOM
security baseline
structured logging
health/readiness endpoint
metrics
trace-id/correlation-id
standard error response
CI quality checks
architecture tests
Docker/build standard

Tavsiya bo‘lishi mumkin

package structure
Hexagonal architecture
CQRS
Spring Modulith
specific mapper library
specific HTTP client style

Majburlamaslik kerak

hamma service’da bir xil murakkab architecture
keraksiz abstraction
ortiqcha custom framework
teamga mos kelmaydigan pattern

23. Eng ko‘p xatolar

Xato 1: Platform starter juda ko‘p magic qiladi

Developer nima bo‘layotganini tushunmaydi.

Yaxshi starter:

default beradi
log qiladi
override imkon beradi
documentation beradi

Xato 2: Product team ehtiyojini eshitmaslik

Platform team:

"Biz shunday dedik, shunday bo‘ladi."

desa, teamlar workaround qiladi.

To‘g‘ri yondashuv:

Platform product sifatida yuritiladi.
Developerlar uning foydalanuvchisi.

Xato 3: BOM update qilinmaydi

BOM bor, lekin eskirib qolsa, foydasi kamayadi.

Platform team doim:

Spring Boot update
security patch
dependency compatibility
CVE monitoring

qilishi kerak.

Xato 4: Convention faqat dokumentatsiyada qoladi

Dokumentatsiya yaxshi, lekin test bo‘lmasa qoida buziladi.

Yaxshi:

README + template + ArchUnit + CI

Xato 5: Hamma narsani common library’ga tashlash

common library haddan tashqari kattalashib ketadi:

common-utils
common-domain
common-service
common-repository

Natija:

hamma service common’ga qaram
version upgrade xavfli
domainlar aralashadi

Qoida:

Common library faqat haqiqatan umumiy infrastructure narsalar uchun. Business logic common’ga chiqmasin.

24. Amaliy roadmap

Platform standardization’ni bosqichma-bosqich qilish:

1. Hozirgi service’larni audit qilish
2. Umumiy muammolarni topish
3. Minimal company-bom yaratish
4. company-observability-starter yaratish
5. company-security-starter yaratish
6. standard error handling starter qo‘shish
7. project template yaratish
8. ArchUnit architecture tests qo‘shish
9. CI pipeline standard qilish
10. migration guide yozish

Birdan hammasini qilish shart emas. Avval eng ko‘p takrorlanadigan va eng xavfli joylardan boshlanadi:

Security
Observability
Dependency management
Error handling

25. Arxitektor xulosasi

Platform standardization - Spring Boot projectlar soni ko‘payganda majburiy darajaga chiqadigan architecture mavzu.

Asosiy g‘oya:

Har team bir xil infrastructure muammolarini qayta yechmasin.
Har service production-ready default bilan boshlansin.
Dependency, security, logging, monitoring va structure markazdan boshqarilsin.
Lekin product teamlar kerak joyda override qila olsin.

Eng muhim qoida:

Platform standardization control uchun emas, tezlik va sifat uchun qilinadi.

Yaxshi platform developerga shuni beradi:

kamroq boilerplate
kamroq xato
tezroq start
osonroq monitoring
xavfsizroq default
osonroq upgrade

SaaS’da tenant odatda bitta mijoz tashkilot bo‘ladi:

Tenant A = Najot Ta'lim
Tenant B = PDP Academy
Tenant C = IT Park

Bitta system:

app.company.com

lekin ichida har tenant alohida ko‘rinadi:

najot.company.com
pdp.company.com
itpark.company.com

Bu mavzu quyidagilarni o‘z ichiga oladi: schema-per-tenant vs DB-per-tenant, TenantContext propagation, Dynamic DataSource routing, Hibernate multi-tenancy strategies, va tenant-aware caching.

1. Multi-tenancy nima uchun kerak?

Agar biz SaaS product qilsangiz, har bir mijoz uchun alohida application ko‘tarish qimmat:

client-a-app
client-a-db

client-b-app
client-b-db

client-c-app
client-c-db

Bu modelda:

• deployment ko‘payadi

• monitoring murakkablashadi

• upgrade qilish qiyinlashadi

• infra xarajat oshadi

• bug fix hamma joyga alohida chiqadi

Multi-tenant SaaS’da esa:

bitta app cluster
ko‘p tenant
tenant bo‘yicha data isolation
bitta platform
bitta release pipeline

2. Tenant nima?

Tenant - systemdan mustaqil foydalanuvchi tashkilot sifatida foydalanadigan birlik.

Masalan:

Tenant = company
Tenant = school
Tenant = marketplace seller
Tenant = bank branch
Tenant = franchise
Tenant = organization

Application ichida deyarli hamma narsa tenant bilan bog‘lanadi:

users
orders
payments
products
roles
settings
subscriptions
invoices
audit logs

3. Tenant aniqlash usullari

Request kelganda system birinchi bo‘lib so‘raydi:

Bu request qaysi tenantga tegishli?

Tenant quyidagi joylardan olinishi mumkin.

1. Subdomain orqali

najot.myapp.com
pdp.myapp.com

Bu SaaS’da juda ko‘p ishlatiladi.

Afzallik:

tenant aniq
URL chiroyli
branding uchun qulay

Kamchilik:

DNS/wildcard certificate kerak
local development biroz murakkab

2. Path orqali

/api/tenants/najot/orders
/api/tenants/pdp/orders

Afzallik:

oddiy
test qilish oson
gateway bilan oson

Kamchilik:

URL har doim tenant bilan ifloslanadi
xavfsizlikda ehtiyot kerak

3. Header orqali

X-Tenant-Id: najot

Afzallik:

internal API uchun qulay
mobile/backend communication uchun yaxshi

Kamchilik:

client headerni qalbakilashtirishi mumkin
auth bilan tekshirish shart

4. JWT claim orqali

{
  "sub": "user-123",
  "tenant_id": "najot",
  "roles": ["ADMIN"]
}

Bu eng xavfsiz variantlardan biri, agar token ishonchli identity provider tomonidan berilgan bo‘lsa.

Spring Security resource server multi-tenancy hujjatida multi-tenant resource server bir nechta bearer token verification strategiyasiga ega bo‘lishi va odatda tenant’ni resolve qilish hamda propagate qilish kerakligi aytiladi. (Home)

4. Eng muhim qoida: tenantni clientdan ko‘r-ko‘rona olmaslik

Yomon:

X-Tenant-Id: pdp
Authorization: user najot tenantiga tegishli

Agar system faqat headerga ishonsa, user boshqa tenant ma’lumotiga kira olishi mumkin.

To‘g‘ri yondashuv:

1. User token tekshiriladi
2. Token ichidagi tenant yoki user membership tekshiriladi
3. Requestdagi tenant shu userga ruxsatlimi - tekshiriladi
4. Keyin TenantContext o‘rnatiladi

Ya’ni:

Tenant resolution - security decision bilan bog‘liq.

5. Multi-tenancy data isolation modellari

Asosiy 3 ta model bor:

1. Shared database + tenant_id column
2. Schema-per-tenant
3. Database-per-tenant

6. Shared database + tenant_id column

Bitta database, bitta schema, har table’da tenant_id bor.

orders table
 ├── id
 ├── tenant_id
 ├── customer_id
 ├── amount
 └── status

Misol:

Query:

SELECT *
FROM orders
WHERE tenant_id = 'najot';

Afzalliklari

eng sodda
eng arzon
bitta migration
bitta connection pool
analytics/report qilish osonroq
kichik/medium SaaS uchun yaxshi

Kamchiliklari

data leak xavfi yuqori
har query tenant filter talab qiladi
katta tenant boshqa tenantlarga ta’sir qilishi mumkin
backup/restore tenant bo‘yicha qiyin
compliance talablariga mos kelmasligi mumkin

Eng katta xavf:

SELECT * FROM orders;

Agar tenant_id filter unutilsa, hamma tenant data chiqadi.

7. Shared DB modelda himoya

1. Har table’da tenant_id

CREATE TABLE orders (
    id BIGSERIAL PRIMARY KEY,
    tenant_id VARCHAR(64) NOT NULL,
    amount NUMERIC NOT NULL
);

2. Composite index

CREATE INDEX idx_orders_tenant_id_id
ON orders (tenant_id, id);

3. Unique constraint tenant bilan

Yomon:

CREATE UNIQUE INDEX ux_users_email
ON users (email);

Bu global email unique qiladi.

Yaxshi:

CREATE UNIQUE INDEX ux_users_tenant_email
ON users (tenant_id, email);

Chunki turli tenantlarda bir xil email bo‘lishi mumkin yoki bo‘lmasligi biznes qaroriga bog‘liq.

8. Schema-per-tenant

Bitta database, lekin har tenant alohida schema’da.

database: saas_db

schema: tenant_najot
 ├── orders
 ├── users
 └── payments

schema: tenant_pdp
 ├── orders
 ├── users
 └── payments

Query:

SELECT * FROM tenant_najot.orders;

yoki connection uchun current schema o‘rnatiladi.

Afzalliklari

data isolation shared-table modeldan kuchliroq
tenant bo‘yicha backup/restore osonroq
bitta DB server ichida boshqariladi
ba’zi compliance holatlariga mosroq

Kamchiliklari

migration har schema uchun yuradi
schema soni ko‘payganda boshqarish qiyinlashadi
connection/session current schema to‘g‘ri o‘rnatilishi shart
cross-tenant reporting murakkabroq

9. Database-per-tenant

Har tenant uchun alohida database.

tenant_najot_db
tenant_pdp_db
tenant_itpark_db

Application requestga qarab kerakli database’ga ulanadi.

Afzalliklari

eng kuchli isolation
tenant bo‘yicha backup/restore oson
katta tenantni alohida scale qilish mumkin
compliance uchun yaxshi
noisy neighbor muammosi kamayadi

Kamchiliklari

eng qimmat
ko‘p DataSource/connection pool kerak
migration murakkab
monitoring murakkab
yangi tenant provisioning murakkab
cross-tenant analytics qiyin

10. Model tanlash jadvali

Arxitektor qaror:

Agar tenantlar ko‘p va kichik bo‘lsa → shared DB + tenant_id
Agar B2B va isolation muhim bo‘lsa → schema-per-tenant
Agar enterprise/compliance talab kuchli bo‘lsa → DB-per-tenant

11. Hybrid model

Real hayotda ko‘pincha hybrid bo‘ladi:

small tenants → shared database
enterprise tenants → dedicated database
regulated tenants → dedicated cluster

Masalan:

Free/Starter plan      → shared DB
Business plan          → schema-per-tenant
Enterprise/Government  → DB-per-tenant

Bu SaaS monetization bilan ham bog‘liq.

12. TenantContext nima?

TenantContext - hozirgi request qaysi tenantga tegishli ekanini application ichida saqlash usuli.

Imperative Spring MVC’da ko‘p hollarda ThreadLocal ishlatiladi:

public final class TenantContext {

    private static final ThreadLocal<String> CURRENT_TENANT = new ThreadLocal<>();

    private TenantContext() {}

    public static void setTenantId(String tenantId) {
        CURRENT_TENANT.set(tenantId);
    }

    public static String getTenantId() {
        return CURRENT_TENANT.get();
    }

    public static void clear() {
        CURRENT_TENANT.remove();
    }
}

13. Tenant filter

Request boshida tenant aniqlanadi:

@Component
public class TenantFilter extends OncePerRequestFilter {

    @Override
    protected void doFilterInternal(
            HttpServletRequest request,
            HttpServletResponse response,
            FilterChain filterChain
    ) throws ServletException, IOException {

        try {
            String tenantId = resolveTenant(request);

            // security check: user shu tenantga tegishlimi?
            TenantContext.setTenantId(tenantId);

            filterChain.doFilter(request, response);
        } finally {
            TenantContext.clear();
        }
    }

    private String resolveTenant(HttpServletRequest request) {
        return request.getHeader("X-Tenant-Id");
    }
}

Eng muhim joy:

finally {
    TenantContext.clear();
}

Agar clear() qilinmasa, thread pool sabab keyingi request eski tenant bilan ishlashi mumkin.

14. Dynamic DataSource Routing

DB-per-tenant yoki ba’zi schema-per-tenant holatlarida requestga qarab DataSource tanlanadi.

Spring’da bu uchun AbstractRoutingDataSource ishlatiladi. Uning determineCurrentLookupKey() metodi odatda thread-bound context’dan lookup key olish uchun implement qilinadi. (Home)

Misol:

public class TenantRoutingDataSource extends AbstractRoutingDataSource {

    @Override
    protected Object determineCurrentLookupKey() {
        return TenantContext.getTenantId();
    }
}

Config:

@Configuration
public class DataSourceConfig {

    @Bean
    public DataSource dataSource() {
        Map<Object, Object> dataSources = new HashMap<>();

        dataSources.put("najot", najotDataSource());
        dataSources.put("pdp", pdpDataSource());

        TenantRoutingDataSource routingDataSource = new TenantRoutingDataSource();
        routingDataSource.setTargetDataSources(dataSources);
        routingDataSource.setDefaultTargetDataSource(defaultDataSource());

        return routingDataSource;
    }
}

Flow:

Request keldi
   ↓
TenantFilter tenantId aniqladi
   ↓
TenantContext.set("najot")
   ↓
Repository query ishladi
   ↓
AbstractRoutingDataSource determineCurrentLookupKey()
   ↓
najot DataSource tanlandi

15. Dynamic DataSource’da katta ehtiyot

Muammo 1: Transaction oldin ochilib ketishi

Agar transaction boshlanganda tenant hali set qilinmagan bo‘lsa, noto‘g‘ri database tanlanadi.

To‘g‘ri tartib:

Security filter
Tenant resolution filter
Transaction
Repository

Muammo 2: Connection pool soni portlab ketadi

Agar 500 tenant va har birida Hikari pool bo‘lsa:

500 tenants × 10 connections = 5000 DB connections

Bu database’ni yiqitishi mumkin.

Yechimlar:

tenantlarni plan bo‘yicha ajratish
lazy DataSource creation
pool size limit
inactive tenant pool close
shared pool strategy
dedicated DB faqat enterprise tenantlarga

Muammo 3: Runtime tenant qo‘shish

Yangi tenant ro‘yxatdan o‘tsa, DataSource map yangilanishi kerak.

Oddiy setTargetDataSources static map bilan qiyin bo‘lishi mumkin.

Production’da ko‘pincha:

TenantRegistry
DataSourceProvider
cache with TTL
dynamic pool creation
tenant provisioning workflow

kerak bo‘ladi.

16. Hibernate multi-tenancy strategies

Hibernate multi-tenancy uchun asosan quyidagi yondashuvlar ishlatiladi:

DATABASE
SCHEMA
DISCRIMINATOR / tenant_id

Hibernate hujjatlarida multi-tenancy support second-level cache bilan ishlashi, cache key ichida tenant identifier kodlanishi aytiladi. (docs.hibernate.org)

DATABASE strategy

Har tenant alohida database connection oladi.

tenant_id → database

Yaxshi:

isolation kuchli
enterprise tenantlar uchun yaxshi

Qiyin:

ko‘p connection pool
migration murakkab
tenant provisioning murakkab

SCHEMA strategy

Bitta database, har tenant alohida schema.

tenant_id → schema

Implementation:

MultiTenantConnectionProvider
CurrentTenantIdentifierResolver

CurrentTenantIdentifierResolver current tenantni beradi.

DISCRIMINATOR strategy

Bitta table ichida tenant_id column.

tenant_id → row filter

Bu eng arzon, lekin eng ehtiyot talab qiladigan model.

17. Tenant-aware caching

Cache multi-tenancy’da juda xavfli joy.

Yomon cache key:

@Cacheable(cacheNames = "orders", key = "#orderId")
public Order getOrder(Long orderId) {
    ...
}

Agar orderId = 10 ikki tenantda ham bo‘lsa:

najot order 10
pdp order 10

cache noto‘g‘ri tenant data qaytarishi mumkin.

Yaxshi:

@Cacheable(
    cacheNames = "orders",
    key = "T(com.company.TenantContext).getTenantId() + ':' + #orderId"
)
public Order getOrder(Long orderId) {
    ...
}

Yoki custom KeyGenerator:

@Component("tenantAwareKeyGenerator")
public class TenantAwareKeyGenerator implements KeyGenerator {

    @Override
    public Object generate(Object target, Method method, Object... params) {
        return TenantContext.getTenantId() + ":" +
                method.getName() + ":" +
                Arrays.deepToString(params);
    }
}

Usage:

@Cacheable(
    cacheNames = "orders",
    keyGenerator = "tenantAwareKeyGenerator"
)
public Order getOrder(Long orderId) {
    ...
}

Qoida:

Cache key ichida tenant bo‘lmasa, multi-tenant system’da data leak xavfi bor.

18. Tenant-aware authorization

Multi-tenancy faqat database emas. Authorization ham tenant-aware bo‘lishi kerak.

Masalan user:

Ali → najot tenantida ADMIN
Ali → pdp tenantida VIEWER

Demak role global emas, tenantga bog‘langan.

Yomon model:

user_roles:
ali = ADMIN

Yaxshi model:

tenant_user_roles:
ali + najot = ADMIN
ali + pdp = VIEWER

Spring Security method-level authorization annotationlar orqali method, class va interface darajasida authorization qo‘llash imkonini beradi. (Home)

Masalan:

@PreAuthorize("@tenantSecurity.canAccessOrder(#orderId, authentication)")
public OrderDto getOrder(Long orderId) {
    ...
}

19. TenantContext propagation: @Async, scheduler, messaging

TenantContext faqat HTTP requestda emas, boshqa joylarda ham kerak bo‘ladi:

@Async
Kafka listener
Rabbit listener
Scheduled job
Domain event listener
WebFlux reactive flow
Batch job

@Async muammosi

ThreadLocal boshqa threadda avtomatik o‘tmaydi.

@Async
public void sendEmail() {
    TenantContext.getTenantId(); // null bo‘lishi mumkin
}

Yechim:

TaskDecorator orqali tenantni ko‘chirish

Misol:

public class TenantTaskDecorator implements TaskDecorator {

    @Override
    public Runnable decorate(Runnable runnable) {
        String tenantId = TenantContext.getTenantId();

        return () -> {
            try {
                TenantContext.setTenantId(tenantId);
                runnable.run();
            } finally {
                TenantContext.clear();
            }
        };
    }
}

Executor config:

@Bean
public ThreadPoolTaskExecutor applicationTaskExecutor() {
    ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
    executor.setTaskDecorator(new TenantTaskDecorator());
    return executor;
}

20. Reactive WebFlux’da TenantContext

WebFlux’da ThreadLocal xavfli, chunki request bitta thread’da boshlanib boshqa thread’da davom etishi mumkin.

Reactor’da context uchun Context ishlatiladi. Reactor hujjatlarida contextCapture operatori ThreadLocal qiymatlarini subscription vaqtida capture qilib Reactor Context’ga o‘tkazishi mumkinligi aytiladi. (projectreactor.io) Micrometer Context Propagation hujjatida context qiymatlari Reactor context va ThreadLocal orasida ko‘chirilishi mumkinligi ko‘rsatiladi. (Micrometer Documentation)

Reactive yondashuv:

return chain.filter(exchange)
        .contextWrite(context -> context.put("tenantId", tenantId));

Keyin:

Mono.deferContextual(ctx -> {
    String tenantId = ctx.get("tenantId");
    return service.process(tenantId);
});

Qoida:

Spring MVC → ThreadLocal ishlashi mumkin
Spring WebFlux → Reactor Context ishlatish kerak

21. Kafka/Rabbit message’da tenant

Event yoki message yuborilganda tenant ham ketishi kerak.

Yomon:

{
  "orderId": 123,
  "status": "PAID"
}

Yaxshi:

{
  "tenantId": "najot",
  "orderId": 123,
  "status": "PAID"
}

Yoki message header:

X-Tenant-Id: najot

Consumer:

@KafkaListener(topics = "orders")
public void listen(OrderPaidEvent event) {
    try {
        TenantContext.setTenantId(event.tenantId());
        orderService.handlePaid(event);
    } finally {
        TenantContext.clear();
    }
}

Qoida:

Async message’da tenant bo‘lmasa, consumer qaysi tenant database yoki cache bilan ishlashini bilmaydi.

22. Tenant provisioning

SaaS’da yangi tenant yaratish oddiy insert emas. Bu workflow.

Masalan:

1. Tenant record yaratish
2. Plan/subscription tanlash
3. DB/schema yaratish
4. Migration yuritish
5. Default roles yaratish
6. Admin user yaratish
7. Default settings yaratish
8. DNS/subdomain sozlash
9. Welcome email yuborish
10. Tenant status ACTIVE qilish

Tenant state:

CREATING
MIGRATING
ACTIVE
SUSPENDED
DELETING
FAILED

Agar provisioning o‘rtada yiqilsa, retry va cleanup kerak.

23. Migration strategy

Shared DB

Migration oddiyroq:

Flyway/Liquibase bitta database uchun yuradi

Schema-per-tenant

Migration har schema uchun yurishi kerak:

tenant_najot → V1, V2, V3
tenant_pdp   → V1, V2, V3
tenant_itpark → V1, V2, V3

DB-per-tenant

Migration har database uchun yuradi:

tenant_najot_db
tenant_pdp_db
tenant_itpark_db

Bu yerda migration orchestration kerak:

qaysi tenant qaysi versionda?
migration failed bo‘lsa nima bo‘ladi?
rolling migration mumkinmi?
downtime kerakmi?

24. Tenant-aware observability

Log, metric va trace tenant-aware bo‘lishi kerak, lekin ehtiyot bilan.

Log:

{
  "service": "order-service",
  "tenantId": "najot",
  "traceId": "abc123",
  "message": "Order created"
}

Metrics’da esa tenant label ehtiyot talab qiladi.

Yomon:

http_requests_total{tenantId="tenant-123456"}

Agar tenantlar juda ko‘p bo‘lsa, metric cardinality portlab ketadi.

Yaxshi:

tenant_tier="enterprise"
region="uz"

yoki faqat enterprise tenantlar uchun alohida metric.

Qoida:

Loglarda tenantId foydali. Metrics label’da tenantId ehtiyot bilan ishlatiladi.

25. Tenant-aware rate limiting

SaaS’da har tenantga limit bo‘lishi mumkin:

Free plan: 100 req/min
Business: 1000 req/min
Enterprise: custom

Rate limit key:

tenantId + endpoint

Masalan:

najot:/api/orders → 1000 req/min
pdp:/api/orders   → 100 req/min

Bu noisy neighbor muammosini kamaytiradi.

26. Tenant-aware feature flags

SaaS’da feature tenant bo‘yicha yoqiladi:

tenant najot → AI_REPORTS enabled
tenant pdp → AI_REPORTS disabled
tenant enterprise-x → BETA_CHECKOUT enabled

Model:

tenant_features
 ├── tenant_id
 ├── feature_key
 └── enabled

Feature flag check:

if (featureFlags.isEnabled("AI_REPORTS", TenantContext.getTenantId())) {
    // new feature
}

27. Tenant configuration

Har tenantda alohida settings bo‘lishi mumkin:

branding
currency
timezone
language
payment provider
notification templates
tax rules
invoice prefix
SLA plan

Bu settings cache qilinadi, lekin cache tenant-aware bo‘lishi shart.

28. Data deletion va compliance

Multi-tenant SaaS’da tenant o‘chirish katta masala.

Shared DB’da:

DELETE FROM orders WHERE tenant_id = 'najot';
DELETE FROM users WHERE tenant_id = 'najot';
DELETE FROM payments WHERE tenant_id = 'najot';

Bu xavfli va murakkab.

DB-per-tenant’da:

drop database tenant_najot_db

ancha toza, lekin backup retention va audit talablarini hisobga olish kerak.

Arxitektor qaror:

Agar tenant offboarding, compliance, data residency muhim bo‘lsa, DB-per-tenant yoki schema-per-tenant kuchliroq.

29. Data residency

Ba’zi tenantlar data ma’lum regionda turishini talab qiladi:

UZ region
EU region
US region

Bu holda tenant registry kerak:

tenant_id → region → cluster/database

Masalan:

najot → uz-central → db-uz-1
enterprise-eu → eu-west → db-eu-2

Request routing:

Gateway tenantni aniqlaydi
tenant regionni topadi
tegishli clusterga yo‘naltiradi

30. Real structure: Spring Boot SaaS

com.company.saas
 ├── tenant
 │    ├── Tenant.java
 │    ├── TenantRegistry.java
 │    ├── TenantContext.java
 │    ├── TenantFilter.java
 │    └── TenantProvisioningService.java
 │
 ├── order
 │    ├── api
 │    ├── application
 │    ├── domain
 │    └── adapter
 │
 ├── payment
 │    ├── api
 │    ├── application
 │    ├── domain
 │    └── adapter
 │
 └── platform
      ├── security
      ├── datasource
      ├── cache
      └── observability

tenant module infrastructure emas, core platform module bo‘ladi.

31. Minimal shared DB implementation

Entity:

@MappedSuperclass
public abstract class TenantAwareEntity {

    @Column(name = "tenant_id", nullable = false, updatable = false)
    private String tenantId;

    @PrePersist
    void assignTenant() {
        this.tenantId = TenantContext.getTenantId();
    }

    public String getTenantId() {
        return tenantId;
    }
}

Order:

@Entity
@Table(name = "orders")
public class OrderEntity extends TenantAwareEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private BigDecimal amount;
}

Lekin bu yetarli emas. Read querylarda ham tenant filter bo‘lishi kerak.

Repository method:

List<OrderEntity> findByTenantIdAndStatus(String tenantId, OrderStatus status);

Yoki specification/global filter yondashuvi ishlatiladi.

32. Eng xavfli xatolar

Xato 1: Tenant filter unutilishi

repository.findById(orderId);

Yomon, chunki orderId boshqa tenantga tegishli bo‘lishi mumkin.

Yaxshi:

repository.findByIdAndTenantId(orderId, TenantContext.getTenantId());

Xato 2: Cache key’da tenant yo‘q

key = "#id"

Yomon.

Yaxshi:

key = "tenantId + ':' + #id"

Xato 3: TenantContext clear qilinmaydi

Thread pool sabab bir tenant ikkinchi tenant requestiga sizib o‘tishi mumkin.

Xato 4: Headerga ko‘r-ko‘rona ishonish

X-Tenant-Id har doim token/user membership bilan tekshirilishi kerak.

Xato 5: Migration strategy oldindan o‘ylanmagan

Tenantlar ko‘paygandan keyin schema yoki database migration juda og‘ir bo‘ladi.

Xato 6: Metrics’da tenantId label qilish

Tenantlar ko‘p bo‘lsa, monitoring system cardinality muammosiga tushadi.

33. Arxitektor decision checklist

Multi-tenancy tanlashdan oldin savollar:

Tenantlar soni qancha bo‘ladi?
Har tenant data hajmi qancha?
Enterprise tenant bormi?
Compliance talablari bormi?
Data residency kerakmi?
Tenant bo‘yicha backup/restore kerakmi?
Cross-tenant analytics kerakmi?
Har tenant alohida customization qiladimi?
Rate limit tenant bo‘yicha bo‘ladimi?
Tenant offboarding qanday ishlaydi?

34. Qisqa tavsiya

Startup SaaS uchun

Shared DB + tenant_id
strict repository convention
tenant-aware cache
tenant-aware auth
strong tests

B2B SaaS uchun

Schema-per-tenant
tenant provisioning workflow
migration orchestration
tenant-aware observability

Enterprise SaaS uchun

Hybrid model
enterprise tenants → DB-per-tenant
small tenants → shared/schema
data residency
dedicated backup/restore

35. Arxitektor xulosasi

Multi-tenancy & SaaS patterns - bu faqat tenant_id column qo‘shish emas.

Bu quyidagi qarorlar majmuasi:

tenant qanday aniqlanadi?
tenant security qanday tekshiriladi?
data isolation qaysi modelda bo‘ladi?
cache tenant-awaremi?
async flow’da tenant yo‘qolmaydimi?
migration qanday yuradi?
tenant provisioning qanday ishlaydi?
observability tenantni ko‘rsatadimi?
enterprise tenantlar qanday ajratiladi?

Eng muhim qoida:

Multi-tenant system’da har bir query, cache, message, log, permission va background job tenant kontekstini hisobga olishi kerak.

Qisqa formula:

Tenant resolution
+ Tenant authorization
+ Tenant context propagation
+ Tenant data isolation
+ Tenant-aware cache/security/observability
= Production-ready SaaS architecture

Bu mavzu quyidagilarni o‘z ichiga oladi: Spring Boot 2 → 3 migration path, Java EE / Jakarta EE namespace migration, Strangler Fig pattern, dependency convergence & CVE management, va API backward compatibility.

1. Migration nima?

Migration - tizimni eski texnologik holatdan yangi holatga ko‘chirish.

Misollar:

Spring Boot 2.7 → Spring Boot 3.x
Java 11 → Java 17 / 21
javax.* → jakarta.*
Spring Security 5 → Spring Security 6
Hibernate 5 → Hibernate 6
Monolith → Modular monolith
Monolith → Microservices
REST API v1 → REST API v2
Old database schema → new database schema

Arxitektor savoli:

"Qanday qilib tizimni yangilaymiz, lekin production’ni buzmaymiz?"

2. Upgrade nima?

Upgrade - mavjud dependency, framework yoki runtime’ni yangi versiyaga ko‘tarish.

Masalan:

<spring-boot.version>2.7.18</spring-boot.version>

dan:

<spring-boot.version>3.3.x</spring-boot.version>

yoki:

<spring-boot.version>3.5.x</spring-boot.version>

ga o‘tish.

Spring Boot rasmiy upgrade hujjatlarida 2.x’dan ko‘tarilishda Spring Boot migration guide va release notes’ni tekshirish tavsiya qilinadi. (Home)

3. Arxitektor darajada migration nimani anglatadi?

Developerlar odatda ko‘pincha shunday o‘ylaydi:

versionni almashtiramiz
compile errorlarni tuzatamiz
testdan o‘tkazamiz
deploy qilamiz

Arxitektorlar esa kengroq qaraydi:

qaysi service birinchi upgrade qilinadi?
qaysi dependencylar conflict beradi?
qaysi API backward compatible qoladi?
rollback qanday bo‘ladi?
database migration qaytariladimi?
clientlar buzilmaydimi?
security patchlar yopildimi?
monitoring migrationdan keyin ishlaydimi?

Ya’ni migration - texnik refactor emas, production risk management.

4. Nega upgrade strategiya kerak?

Agar upgrade tartibsiz qilinsa:

service compile bo‘lmaydi
runtime’da ClassNotFoundException chiqadi
javax/jakarta conflict bo‘ladi
security config buziladi
Hibernate querylar boshqacha ishlaydi
API response o‘zgarib ketadi
clientlar yiqiladi
rollback qiyinlashadi

Katta system’da eng xavfli holat:

"Hammasini bir PR’da upgrade qilamiz."

To‘g‘ri strategiya:

audit
step-by-step upgrade
compatibility layer
test coverage
canary rollout
monitoring
rollback plan

5. Spring Boot 2 → 3 migration path

Spring Boot 3 migration eng katta o‘zgarishlardan biri, chunki u:

Java 17+ talab qiladi
Spring Framework 6 asosida ishlaydi
Jakarta EE 9 API ishlatadi
javax.* o‘rniga jakarta.* ishlatadi
Spring Security 6 o‘zgarishlari bor
Hibernate 6 o‘zgarishlari bor

Spring jamoasi Spring Boot 3.0 Spring Framework 6.0 asosida bo‘lishi, Java 17 yoki undan yuqorini talab qilishi va Jakarta EE 9 jakarta.* API’lariga o‘tishini e’lon qilgan. (Home)

Tavsiya migration yo‘li

Spring Boot 3 migration guide Spring Boot 3.0'ga o‘tishdan oldin eng oxirgi 2.7.x versiyaga upgrade qilishni tavsiya qiladi. (GitHub)

Amaliy yo‘l:

1. Spring Boot 2.x ichida eng oxirgi 2.7.x ga o‘tish
2. Java versionni 17+ qilish
3. Deprecated API’larni tozalash
4. Spring Security 5.8 migration qilish
5. javax.* importlarni jakarta.* ga tayyorlash
6. Third-party dependency compatibility tekshirish
7. Spring Boot 3.x ga o‘tish
8. Hibernate 6 / Security 6 / validation o‘zgarishlarini tuzatish
9. Full regression test
10. Canary deploy

6. Nega avval 2.7.x?

Agar biz to‘g‘ridan-to‘g‘ri eski 2.3 yoki 2.4'dan Boot 3'ga o‘tsangiz, xatolar juda ko‘payadi.

Yomon:

Spring Boot 2.3 → Spring Boot 3.3

Yaxshi:

Spring Boot 2.3 → 2.7.x → 3.x

Sabab:

2.7.x migration warninglarni beradi
deprecated API’larni ko‘rish osonlashadi
dependencylar Boot 3 ga yaqinlashadi
Security 5.8 orqali Security 6 ga tayyorlanadi

7. Java EE → Jakarta EE migration

Spring Boot 3 bilan katta o‘zgarish:

javax.* → jakarta.*

Masalan:

import javax.persistence.Entity;
import javax.validation.Valid;
import javax.servlet.Filter;

bo‘ladi:

import jakarta.persistence.Entity;
import jakarta.validation.Valid;
import jakarta.servlet.Filter;

Bu oddiy import almashtirishga o‘xshaydi, lekin real project’da katta ta’sir qiladi.

Ta’sir qiladigan joylar

JPA entities
Bean Validation
Servlet API
JAX-RS
JMS
JSON-B
XML binding
third-party libraries
generated code
OpenAPI generated models

Misol:

import javax.persistence.Entity;
import javax.persistence.Id;

yangisi:

import jakarta.persistence.Entity;
import jakarta.persistence.Id;

8. Eng ko‘p chiqadigan muammo: dependency conflict

Boot 3 jakarta.* ishlatadi. Lekin ba’zi eski librarylar hali ham javax.* ishlatadi.

Muammo:

Application Boot 3'da
lekin eski dependency javax.servlet.Filter kutyapti
runtime’da ClassNotFoundException chiqadi

Yechim:

librarylarni Boot 3 compatible versiyaga ko‘tarish
eski libraryni almashtirish
generated clientlarni qayta generate qilish
javax/jakarta aralashmasini tozalash

9. OpenRewrite bilan migration

Katta codebase’da qo‘lda import almashtirish xavfli va sekin.

OpenRewrite Spring Boot 3 migration recipe’lari build files, deprecated/preferred API, configuration settings va framework migrationlarni avtomatik o‘zgartirishga yordam beradi. (OpenRewrite Docs)

Masalan migration yordam berishi mumkin:

javax → jakarta importlar
Spring Boot version update
deprecated property migration
Spring Security DSL update
old API’dan new API’ga o‘tish

Lekin qoida:

OpenRewrite migrationni tezlashtiradi, lekin arxitektor qarorini almashtirmaydi. Har doim review, test va rollout kerak.

10. Migration branch strategy

Katta upgrade uchun yaxshi branch strategiya:

main
 ├── migration/spring-boot-3
      ├── step-1-java-17
      ├── step-2-boot-2.7-latest
      ├── step-3-jakarta
      ├── step-4-security-6
      └── step-5-boot-3

Yoki kichik PR’lar:

PR 1: Java 17 support
PR 2: Deprecated API cleanup
PR 3: Dependency alignment
PR 4: javax → jakarta
PR 5: Spring Security migration
PR 6: Hibernate fixes
PR 7: Boot 3 switch

Yomon amaliyot:

500 ta file o‘zgargan bitta ulkan PR

Bunday PR review qilish qiyin, rollback qilish qiyin.

11. Spring Security migration

Spring Security 6'da eski config yondashuvlar ko‘p o‘zgargan.

Eski uslub:

@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
}

Yangi uslub:

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        return http
                .authorizeHttpRequests(auth -> auth
                        .requestMatchers("/actuator/health").permitAll()
                        .anyRequest().authenticated()
                )
                .oauth2ResourceServer(oauth -> oauth.jwt())
                .build();
    }
}

Migration’da quyidagilarni tekshirish kerak:

endpoint authorization
CSRF policy
CORS
JWT claim mapping
role prefix
method security
password encoder
actuator security

Security migration’da eng xavfli narsa:

Application compile bo‘lishi mumkin, lekin security behavior o‘zgarib ketadi.

12. Hibernate 5 → 6 migration

Spring Boot 3 odatda Hibernate 6 bilan keladi.

Tekshiriladigan joylar:

custom queries
native queries
JPQL syntax
dialect settings
custom UserType
pagination behavior
naming strategy
lazy loading
criteria API

Agar projectda ko‘p custom query bo‘lsa, migration risk yuqori.

Testlar:

repository integration tests
Testcontainers bilan real database
migration scripts
slow query monitoring
N+1 checks

13. Configuration property migration

Spring Boot versiyalarda property nomlari o‘zgarishi mumkin.

Masalan:

management.metrics.export.prometheus.enabled: true

ba’zi versiyalarda boshqacha konfiguratsiyaga o‘tgan bo‘lishi mumkin.

Migration strategy:

old propertylarni scan qilish
metadata warninglarni ko‘rish
startup loglarni tekshirish
deprecated config report olish
configuration tests yozish

Spring Boot release notes va migration guide har release uchun "breaking change" va property o‘zgarishlarini tekshirishda asosiy manba bo‘ladi. (Home)

14. Dependency convergence

Dependency convergence - project ichida bir xil library’ning turli versiyalari conflict qilmasligi.

Masalan:

service A:
  jackson-databind 2.15

dependency X:
  jackson-databind 2.13

dependency Y:
  jackson-databind 2.16

Natija:

NoSuchMethodError
ClassCastException
runtime conflict
security vulnerability

Arxitektor darajada yechim:

BOM ishlatish
dependencyManagement markazlashtirish
Maven Enforcer / Gradle constraints
dependency tree audit
CI’da vulnerability scan

15. BOM orqali boshqarish

Platform standardization mavzusida aytganimizdek, company BOM dependency versionlarni markazlashtiradi.

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.company.platform</groupId>
            <artifactId>company-bom</artifactId>
            <version>2.0.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Foyda:

hamma service bir xil dependency baseline’da
CVE patch markazdan qilinadi
upgrade PR’lar standart bo‘ladi
conflict kamayadi

16. CVE management

CVE - dependency yoki platformadagi xavfsizlik zaifligi.

Masalan:

Jackson CVE
Netty CVE
Tomcat CVE
Spring Security CVE
Logback CVE
PostgreSQL driver CVE

CVE strategy:

1. SBOM generate qilish
2. Dependency scan qilish
3. Severity bo‘yicha triage
4. Exploitability tekshirish
5. Patched versionga upgrade
6. Regression test
7. Rollout
8. Audit record

Spring OSS support policy’da major release’lar 3 yilgacha, minor release’lar esa kamida 12 oy qo‘llab-quvvatlanishi aytilgan. (Home) Shuning uchun arxitektor faqat "hozir ishlayapti" deb emas, support lifecycle bo‘yicha ham reja qiladi.

17. Release cadence & EOL planning

EOL - End of Life. Ya’ni versiya endi free public security/bug fix olmaydi.

Arxitektor har service uchun matrix yuritadi:

Yaxshi platform governance:

har quarter dependency review
EOL’dan 6 oy oldin migration plan
critical CVE bo‘lsa emergency patch
major upgrade uchun pilot service

18. Strangler Fig Pattern

Strangler Fig pattern - legacy systemni birdan rewrite qilmasdan, sekin-sekin yangi system bilan almashtirish.

G‘oya:

Old monolith saqlanadi
yangi featurelar yangi service/module’da yoziladi
traffic asta-sekin yangi tomonga yo‘naltiriladi
legacy qismi qisqarib boradi
oxiri eski qism o‘chiriladi

Oddiy ko‘rinish

Client
  ↓
API Gateway
  ├── /old/orders  → legacy monolith
  ├── /new/orders  → new order service
  └── /payments    → new payment service

Yoki:

/orders eski read → legacy
/orders yangi write → new service

19. Strangler Fig qachon kerak?

Kerak bo‘ladi:

katta monolith bor
rewrite xavfli
business to‘xtamasligi kerak
domainlarni asta ajratish kerak
teamlar parallel ishlashi kerak
legacy code test qilinmaydi

Kerak bo‘lmasligi mumkin:

kichik project
legacy juda oddiy
full rewrite tez va xavfsiz
business critical emas

20. Strangler migration bosqichlari

1. Legacy system boundary mapping
2. Domain/module tanlash
3. API gateway/proxy qo‘yish
4. Yangi module/service yaratish
5. Data sync strategiya tanlash
6. Traffic routing
7. Dual-write yoki event sync
8. Canary rollout
9. Legacy endpointni deprecated qilish
10. Eski kodni olib tashlash

21. Eng xavfli qism: data migration

Legacy’dan yangi systemga o‘tishda data masalasi eng qiyin.

Variantlar:

Big bang migration
Dual-write
CDC - Change Data Capture
Event-driven sync
Read from legacy, write to new
Read from new, fallback to legacy

Big bang

Bir kechada hamma data ko‘chiriladi
old system o‘chadi
new system yoqiladi

Risk yuqori.

Dual-write

Application eski DB va yangi DB’ga yozadi

Risk:

biri yozildi, biri yozilmadi
consistency muammosi
rollback qiyin

CDC

Legacy database change log → Debezium → Kafka → new system

Ko‘p enterprise migrationlarda CDC xavfsizroq bo‘lishi mumkin.

22. API backward compatibility

Upgrade vaqtida eng muhim qoidalardan biri:

Existing clientlar buzilmasligi kerak.

Breaking change misollar:

field nomi o‘zgardi
enum value o‘zgardi
required field qo‘shildi
response structure o‘zgardi
HTTP status o‘zgardi
pagination format o‘zgardi
error response o‘zgardi
auth scope o‘zgardi

Yomon:

{
  "userName": "Ali"
}

yangisi:

{
  "fullName": "Ali"
}

Bu clientni buzadi.

Yaxshi:

{
  "userName": "Ali",
  "fullName": "Ali"
}

keyin deprecation period.

23. API versioning strategy

Variantlar:

URI versioning

/api/v1/orders
/api/v2/orders

Sodda va tushunarli.

Header versioning

Accept: application/vnd.company.orders-v2+json

Toza, lekin clientlar uchun murakkabroq.

Compatible evolution

Bitta endpoint, faqat backward compatible o‘zgarishlar.

field qo‘shish mumkin
field o‘chirish mumkin emas
required qilish mumkin emas
enumni ehtiyot bilan kengaytirish kerak

24. Backward compatible o‘zgarishlar

Odatda xavfsiz:

response’ga optional field qo‘shish
yangi endpoint qo‘shish
yangi optional request field qo‘shish
pagination metadata qo‘shish
new enum value - ehtiyot bilan

Xavfli:

field rename
field remove
type change
required field qo‘shish
error code o‘zgartirish
HTTP status o‘zgartirish
auth requirement kuchaytirish

25. Deprecation policy

Har API uchun deprecation qoidasi bo‘lishi kerak:

1. Old field/endpoint deprecated deb belgilanadi
2. Documentation’da yoziladi
3. Clientlarga xabar beriladi
4. Metrics bilan usage o‘lchanadi
5. Migration deadline beriladi
6. Deadline’dan keyin olib tashlanadi

Masalan:

Deprecation: true
Sunset: Wed, 31 Dec 2026 23:59:59 GMT

26. Contract testing

Migration’da contract test juda foydali.

Maqsad:

Provider o‘zgarsa ham consumer buzilmasin

Masalan:

order-service API response o‘zgardi
mobile app yoki payment-service buzilmasligi kerak

Contract test tools:

Spring Cloud Contract
Pact
OpenAPI diff tools
consumer-driven contract tests

27. Database migration strategy

Database migration ham upgrade strategy’ning bir qismi.

Qoida:

Database migration backward compatible bo‘lishi kerak.

Yomon:

ALTER TABLE users DROP COLUMN username;

Bu eski applicationni buzadi.

Yaxshi expand-contract pattern:

1. Expand: yangi column qo‘shish
2. App eski va yangi column bilan ishlaydi
3. Backfill data
4. Client/app yangi columnga o‘tadi
5. Contract: eski columnni keyin olib tashlash

Expand-contract misol

1. Yangi column:

ALTER TABLE users ADD COLUMN full_name VARCHAR(255);

2. App ikkala fieldni yozadi:

username + full_name

3. Backfill:

UPDATE users SET full_name = username WHERE full_name IS NULL;

4. App faqat full_name o‘qiydi.

5. Keyingi release’da:

ALTER TABLE users DROP COLUMN username;

28. Rollout strategy

Upgrade production’da birdan hamma userga berilmasligi kerak.

Variantlar:

blue-green deployment
canary deployment
rolling deployment
feature flags
dark launch
shadow traffic

Canary

1% traffic → new version
5% traffic → new version
25% traffic → new version
100% traffic → new version

Bu vaqt davomida kuzatiladi:

error rate
latency
CPU/memory
database query time
business metrics
security failures

29. Rollback strategy

Migration’dan oldin rollback aniq bo‘lishi kerak.

Savollar:

old app new database schema bilan ishlaydimi?
migration reversiblemi?
data o‘zgargan bo‘lsa rollback qanday?
message format backward compatiblemi?
clientlar eski API’ga qayta oladimi?

Eng yomon holat:

new app deploy qilindi
database destructive migration qildi
app yiqildi
old app schema bilan ishlamaydi
rollback imkonsiz

Shuning uchun database migration expand-contract bo‘lishi kerak.

30. Observability during migration

Migration monitoring’siz qilinmaydi.

Kerakli dashboard:

startup errors
HTTP 4xx/5xx
p95/p99 latency
DB connection pool
slow queries
Kafka consumer lag
memory/GC
security denied requests
business KPI

Loglarda migration flag foydali:

{
  "service": "order-service",
  "version": "3.0.0-migration",
  "springBoot": "3.5.x",
  "traceId": "abc123",
  "message": "Order created"
}

31. Spring Boot 2 → 3 migration checklist

Java 17+ ga o‘tildi
Spring Boot latest 2.7.x ga ko‘tarildi
Deprecated API’lar tozalandi
javax.* importlar jakarta.* ga o‘tdi
Spring Security config yangilandi
Hibernate queries test qilindi
Validation imports yangilandi
Servlet filters yangilandi
OpenAPI/generated code yangilandi
Third-party libraries Boot 3 compatible
Actuator endpoints tekshirildi
Metrics/tracing tekshirildi
Integration tests o‘tdi
Performance baseline solishtirildi
Canary deploy qilindi
Rollback plan bor

32. Real migration example

Tasavvur qilamiz:

order-service
Java 11
Spring Boot 2.5
Spring Security old config
Hibernate 5
javax.persistence

To‘g‘ri migration:

Step 1: Java 17 support qo‘shish
Step 2: Spring Boot 2.7.x ga o‘tish
Step 3: Security 5.8 style configga o‘tish
Step 4: Deprecated configlarni tozalash
Step 5: javax → jakarta migration
Step 6: Boot 3 ga o‘tish
Step 7: Hibernate querylarni tuzatish
Step 8: Testcontainers bilan DB test
Step 9: Canary deploy
Step 10: full rollout

33. Eng ko‘p xatolar

Xato 1: Big bang upgrade

Java 11 → 21
Boot 2.4 → 3.5
Security 5 → 6
Hibernate 5 → 6
hammasi bitta PR’da

Bu xavfli.

Xato 2: Compile bo‘lsa yetadi deb o‘ylash

Migration’da runtime behavior muhim:

security rules
transaction behavior
serialization
query behavior
cache behavior
metrics/tracing

Xato 3: Database rollback o‘ylanmagan

Destructive migration rollbackni o‘ldiradi.

Xato 4: Third-party dependency tekshirilmagan

Eski SDK javax.* ishlatsa, Boot 3'da muammo beradi.

Xato 5: API compatibility buzilgan

Backend upgrade bo‘ldi, lekin mobile app eski response kutyapti.

34. Arxitektor xulosasi

Migration & upgrade strategy - bu production systemni yangilashda xavfni kamaytirish san’ati.

Asosiy qoida:

Upgrade step-by-step qilinadi.
Breaking change oldindan aniqlanadi.
API backward compatibility saqlanadi.
Database migration expand-contract bo‘ladi.
Dependency/CVE markazdan boshqariladi.
Rollout canary/blue-green bilan qilinadi.
Rollback oldindan tayyor bo‘ladi.

Spring Boot 2 → 3 uchun qisqa formula:

Latest 2.7.x
+ Java 17+
+ javax → jakarta
+ Security 6 migration
+ Hibernate 6 validation
+ dependency compatibility
+ full regression
+ canary rollout
= xavfsiz Spring Boot 3 migration

Spring Modulith quyidagi mavzularni o‘z ichiga oladi: application modules & boundaries, inter-module event communication, module integration tests, documenting module structure, va modulith’dan microservices’ga evolyutsiya.

Spring’ning rasmiy hujjatlarida Spring Modulith alohida modullarni izolyatsiyada yoki boshqa modullar bilan birga integration test qilish imkonini berishi aytiladi. (Home) Shuningdek, modullarni bo‘sh bog‘langan saqlash uchun ular orasida Spring application event’lari orqali aloqa qilish tavsiya qilinadi. (Home)

1. Spring Modulith nima?

Spring Modulith - bu microservice emas. Bu modular monolith qurish usuli.

Ya’ni:

bitta application
bitta deploy
bitta database bo‘lishi mumkin
lekin ichida aniq ajratilgan biznes modullar bor

Masalan:

marketplace-app
 ├── order
 ├── payment
 ├── delivery
 ├── catalog
 ├── customer
 └── notification

Hammasi bitta Spring Boot project ichida. Lekin order module payment module ichki classlarini xohlagancha ishlata olmaydi.

2. Nega Spring Modulith kerak?

Oddiy monolith boshida juda qulay:

Controller → Service → Repository

Lekin project kattalashganda shunday bo‘lib ketadi:

OrderService -> PaymentRepository
PaymentService -> DeliveryService
NotificationService -> OrderRepository
CatalogService -> PaymentService

Ya’ni hamma classlar bir-biriga bog‘lanib ketadi.

Natija:

• bitta joyni o‘zgartirsak boshqa joy buziladi

• testlar og‘irlashadi

• yangi developer projectni tushunishga qiynaladi

• microservice’ga ajratish deyarli imkonsiz bo‘ladi

• dependency tartibsiz bo‘ladi

Spring Modulith shuni oldini oladi:

Monolith ichida microservice’ga o‘xshash intizom beradi, lekin deploy murakkabligini oshirmaydi.

3. Modular Monolith vs Microservices

Arxitektor uchun muhim qoida:

Avval modular monolith qilib to‘g‘ri chegaralarni topish, keyin kerak bo‘lsa microservice’ga ajratish - ko‘p holatda xavfsizroq yo‘l.

4. Application Modules & Boundaries

Spring Modulith’da module odatda package orqali aniqlanadi.

Masalan:

com.company.shop
 ├── order
 ├── payment
 ├── delivery
 └── notification

Har bir yuqori darajadagi package alohida application module sifatida qaraladi.

Yaxshi structure

com.company.shop.order
 ├── OrderManagement.java
 ├── OrderCreatedEvent.java
 ├── internal
 │    ├── OrderService.java
 │    ├── OrderRepository.java
 │    └── OrderJpaEntity.java
 └── web
      └── OrderController.java

Bu yerda:

Yomon structure

com.company.shop
 ├── controller
 ├── service
 ├── repository
 ├── entity
 └── dto

Bu texnik qatlam bo‘yicha bo‘lingan. Katta project’da biznes chegaralar yo‘qoladi.

Yaxshiroq:

com.company.shop
 ├── order
 ├── payment
 ├── delivery
 └── customer

Bu package-by-domain.

5. Public API va internal classlar

Spring Modulith’da eng muhim tushuncha:

Boshqa modul faqat public API’dan foydalansin, internal classlarga kirmasin.

Masalan payment module:

payment
 ├── PaymentManagement.java
 ├── PaymentCompletedEvent.java
 └── internal
      ├── PaymentService.java
      ├── PaymentRepository.java
      └── PaymentProcessor.java

order module quyidagini ishlatishi mumkin:

payment.PaymentManagement
payment.PaymentCompletedEvent

Lekin buni ishlatmasligi kerak:

payment.internal.PaymentService
payment.internal.PaymentRepository

Chunki internal - modulning ichki implementatsiyasi.

6. Module facade

Module facade - boshqa modullar bilan gaplashish uchun public contract.

Masalan:

package com.company.shop.payment;

public interface PaymentManagement {

    PaymentResult pay(PaymentRequest request);

}

Implementation esa internal ichida turadi:

package com.company.shop.payment.internal;

import com.company.shop.payment.PaymentManagement;

@Service
class PaymentService implements PaymentManagement {

    @Override
    public PaymentResult pay(PaymentRequest request) {
        // payment business logic
        return new PaymentResult(true);
    }
}

Bu yondashuv yaxshi, chunki boshqa module faqat PaymentManagement bilan ishlaydi.

7. Inter-module communication

Modullar ikki xil yo‘l bilan gaplashadi:

1. Synchronous call

Bir module boshqa module’ning public API’sini chaqiradi.

@Service
class OrderService {

    private final PaymentManagement paymentManagement;

    OrderService(PaymentManagement paymentManagement) {
        this.paymentManagement = paymentManagement;
    }

    void createOrder(CreateOrderCommand command) {
        // order yaratish
        paymentManagement.pay(new PaymentRequest(command.customerId(), command.amount()));
    }
}

Bu oddiy va tushunarli. Lekin coupling kuchliroq bo‘ladi.

2. Event-based communication

Bir module event chiqaradi, boshqa module uni eshitadi.

public record OrderCreatedEvent(
        Long orderId,
        Long customerId,
        BigDecimal totalAmount
) {}

Order module event publish qiladi:

@Service
class OrderService {

    private final ApplicationEventPublisher events;

    OrderService(ApplicationEventPublisher events) {
        this.events = events;
    }

    @Transactional
    void createOrder(CreateOrderCommand command) {
        Order order = Order.create(command.customerId(), command.items());

        // save order...

        events.publishEvent(new OrderCreatedEvent(
                order.getId(),
                order.getCustomerId(),
                order.getTotalAmount()
        ));
    }
}

Payment module event’ni eshitadi:

@Component
class PaymentOnOrderCreated {

    @EventListener
    void on(OrderCreatedEvent event) {
        // payment boshlash
    }
}

Bu yondashuvda order module payment module borligini bilmaydi.

8. @ApplicationModuleListener

Spring Modulith’da event listener uchun maxsus annotation ishlatiladi:

@ApplicationModuleListener
void on(OrderCreatedEvent event) {
    // boshqa module eventiga reaksiya
}

Bu oddiy @EventListenerdan kuchliroq. Odatda quyidagi maqsadlarda ishlatiladi:

• module’lar orasidagi event handling

• transaction tugagandan keyin eventni qayta ishlash

• async processing

• module boundary’ni toza saqlash

Arxitektor nuqtayi nazaridan:

Agar bir module boshqa module’ning ichki service’ini chaqirmasdan event orqali ishlasa, coupling kamayadi.

9. Real flow: Order → Payment → Delivery

Online shop misoli:

1. User order yaratadi
2. Order module OrderCreatedEvent chiqaradi
3. Payment module eventni eshitadi
4. Payment muvaffaqiyatli bo‘lsa PaymentCompletedEvent chiqaradi
5. Delivery module PaymentCompletedEvent’ni eshitadi
6. Delivery boshlanadi

Structure:

shop
 ├── order
 │    ├── OrderManagement.java
 │    ├── OrderCreatedEvent.java
 │    └── internal
 │         └── OrderService.java
 │
 ├── payment
 │    ├── PaymentCompletedEvent.java
 │    └── internal
 │         └── PaymentService.java
 │
 └── delivery
      └── internal
           └── DeliveryService.java

Flow:

OrderCreatedEvent
        ↓
Payment module
        ↓
PaymentCompletedEvent
        ↓
Delivery module

Bu hali microservice emas. Lekin architecture microservice’ga o‘xshab toza.

10. Module verification

Spring Modulith’ning eng katta foydasi - module boundary test.

Masalan:

class ModularityTests {

    ApplicationModules modules =
            ApplicationModules.of(ShopApplication.class);

    @Test
    void verifiesModularStructure() {
        modules.verify();
    }
}

Bu test quyidagilarni tekshiradi:

• module’lar orasida cyclic dependency bormi

• internal package tashqaridan ishlatilganmi

• module ruxsat berilmagan module’ga bog‘langanmi

• package structure buzilganmi

Masalan, order module buni qilsa:

import com.company.shop.payment.internal.PaymentService;

test yiqiladi.

Bu juda kuchli narsa:

Architecture faqat diagrammada emas, test bilan majburlanadi.

11. Module integration tests

Oddiy Spring Boot test ko‘pincha butun application context’ni ko‘taradi:

@SpringBootTest
class OrderTest {
}

Katta project’da bu sekin.

Spring Modulith bilan faqat bitta modulni test qilish mumkin:

@ApplicationModuleTest
class OrderModuleTest {

    @Test
    void createsOrder() {
        // faqat order module konteksti
    }
}

Rasmiy hujjatlarda Spring Modulith application module’larni izolyatsiyada yoki boshqa modullar bilan kombinatsiyada integration test qilish imkonini berishi ko‘rsatilgan. (Home)

Foydasi:

• test tezroq

• module mustaqilligi tekshiriladi

• hidden dependency topiladi

• architecture real ishlashi isbotlanadi

12. Published events testing

Event chiqdimi yoki yo‘qmi - test qilish mumkin.

Masalan:

@ApplicationModuleTest
class OrderModuleTest {

    @Test
    void publishesOrderCreatedEvent(
            PublishedEvents events,
            OrderManagement orders
    ) {
        orders.createOrder(new CreateOrderCommand(...));

        assertThat(events)
                .contains(OrderCreatedEvent.class);
    }
}

Bu nima beradi?

Order yaratish use case’i payment’ni bevosita chaqirmaydi, faqat event chiqaradi. Test shuni isbotlaydi.

Spring Modulith PublishedEvents orqali test davomida publish qilingan eventlarni tekshirishga imkon beradi. (Home)

13. Documenting module structure

Spring Modulith module structure’ni dokumentatsiya qilishga ham yordam beradi.

Masalan:

@Test
void writeDocumentation() {
    ApplicationModules modules =
            ApplicationModules.of(ShopApplication.class);

    new Documenter(modules)
            .writeModulesAsPlantUml()
            .writeIndividualModulesAsPlantUml();
}

Natijada module dependency diagrammalar olish mumkin.

Bu arxitektor uchun foydali:

• yangi developer projectni tez tushunadi

• real dependency ko‘rinadi

• diagramma koddan generate bo‘ladi

• eski qo‘lda chizilgan diagrammadan ko‘ra ishonchliroq

14. Spring Modulith va DDD

Spring Modulith DDD bilan juda yaxshi mos keladi.

DDD’da bounded context bor:

Order Context
Payment Context
Delivery Context
Customer Context

Spring Modulith’da ular package/module sifatida ajratiladi:

com.company.shop.order
com.company.shop.payment
com.company.shop.delivery
com.company.shop.customer

Ya’ni:

15. Modulith’dan microservice’ga o‘tish

Spring Modulith’ning kuchli tomoni:

Avval module chegaralarini bitta application ichida to‘g‘ri topasiz, keyin kerak bo‘lsa alohida service qilib ajratasiz.

Masalan boshida:

shop-app
 ├── order
 ├── payment
 └── delivery

Keyin traffic oshsa yoki team alohida ishlashi kerak bo‘lsa:

order-service
payment-service
delivery-service

Agar oldindan module boundary yaxshi bo‘lsa, ajratish osonroq bo‘ladi.

Agar boshidan hamma joy aralash bo‘lsa:

OrderService -> PaymentRepository
PaymentService -> OrderRepository
DeliveryService -> PaymentService

microservice’ga ajratish juda og‘riqli bo‘ladi.

16. Qachon Spring Modulith ishlatish kerak?

Ishlatish yaxshi

• project o‘rta yoki katta bo‘lsa

• biznes domain aniq modullarga bo‘linsa

• microservice qilishga shoshilmasak

• monolith ichida tartib kerak bo‘lsa

• jamoa bitta codebase’da ishlasa

• module boundary’ni test bilan nazorat qilmoqchi bo‘lsangiz

Shart emas

• juda kichik CRUD project

• MVP juda tez yozilishi kerak bo‘lsa

• domain hali aniq bo‘lmasa

• jamoa package-by-domain’ni ham tushunmasa

• architecture intizomi talab qilinmasa

17. Eng ko‘p xatolar

Xato 1: Module nomini texnik qilish

Yomon:

controller
service
repository

Yaxshi:

order
payment
delivery
customer

Xato 2: Internal classlarni tashqaridan ishlatish

Yomon:

import com.company.shop.payment.internal.PaymentService;

Yaxshi:

import com.company.shop.payment.PaymentManagement;

yoki event:

OrderCreatedEvent

Xato 3: Event’ni hamma narsaga ishlatish

Event yaxshi, lekin hamma narsa event bo‘lishi shart emas.

Masalan, real vaqt javob kerak bo‘lsa:

Order -> Payment public API call

Agar loose coupling kerak bo‘lsa:

OrderCreatedEvent -> Payment listener

Xato 4: Bitta module ichida hamma narsani saqlash

Yomon:

core
common
shared

Agar hamma narsa commonga ketaversa, module boundary buziladi.

Xato 5: Modulith’ni microservice deb o‘ylash

Spring Modulith:

bitta process
bitta deploy
module boundary ichki darajada

Microservice:

alohida process
alohida deploy
network communication
alohida observability

18. Amaliy structure - tavsiya

com.company.shop
 ├── order
 │    ├── OrderManagement.java
 │    ├── OrderCreatedEvent.java
 │    ├── package-info.java
 │    └── internal
 │         ├── OrderService.java
 │         ├── OrderRepository.java
 │         └── OrderEntity.java
 │
 ├── payment
 │    ├── PaymentManagement.java
 │    ├── PaymentCompletedEvent.java
 │    ├── package-info.java
 │    └── internal
 │         ├── PaymentService.java
 │         └── PaymentRepository.java
 │
 ├── delivery
 │    ├── DeliveryManagement.java
 │    ├── package-info.java
 │    └── internal
 │         └── DeliveryService.java
 │
 └── notification
      ├── NotificationManagement.java
      └── internal
           └── NotificationService.java

19. Minimal dependency

Maven misol:

<dependency>
    <groupId>org.springframework.modulith</groupId>
    <artifactId>spring-modulith-starter-core</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.modulith</groupId>
    <artifactId>spring-modulith-starter-test</artifactId>
    <scope>test</scope>
</dependency>

Test starter rasmiy hujjatlarda module integration testing uchun ishlatilishi ko‘rsatilgan. (Home)

20. Arxitektor xulosasi

Spring Modulith’ning asosiy qiymati:

Monolith qulayligini saqlaydi.
Microservice intizomini beradi.
Module boundary’ni test bilan tekshiradi.
Event orqali coupling’ni kamaytiradi.
Keyinchalik microservice’ga o‘tishni osonlashtiradi.

Eng muhim qoida:

Spring Modulith ishlatishdan maqsad annotation qo‘shish emas. Maqsad - biznes modullar orasidagi chegarani kodda ham, testda ham, dokumentatsiyada ham aniq qilish.

Bu blok quyidagilarni o‘z ichiga oladi: SAGA orchestration vs choreography, Transactional Outbox + Debezium CDC, Idempotent Consumer, Distributed Locking, va Two-Phase Commit’dan qachon qochishni hal qiladi.

1. Muammo nimada?

Monolith’da bitta database bo‘lsa, transaction oddiy:

Order yaratildi
Payment yozildi
Stock kamaytirildi
Delivery yaratildi
        ↓
bitta database transaction

Kodda:

@Transactional
public void checkout() {
    orderRepository.save(order);
    paymentRepository.save(payment);
    stockRepository.decrease(productId);
    deliveryRepository.create(orderId);
}

Agar xato bo‘lsa:

rollback

Hammasi bitta database ichida qaytadi.

2. Distributed system’da muammo

Microservice architecture’da har service odatda o‘z database’iga ega:

order-service       → order_db
payment-service     → payment_db
inventory-service   → inventory_db
delivery-service    → delivery_db

Endi bitta @Transactional bilan hammasini boshqarib bo‘lmaydi.

Masalan checkout flow:

1. Order yaratish
2. Payment olish
3. Stock kamaytirish
4. Delivery yaratish

Agar 3-qadamda stock kamaytirish yiqilsa:

Order yaratildi
Payment olindi
Stock kamaymadi
Delivery yaratilmadi

System "yarim bajarilgan" holatda qoladi.

Distributed data patterns shuni boshqarish uchun kerak.

3. Muhim tushuncha: local transaction

Har service faqat o‘z database’ida transaction qila oladi.

order-service:
@Transactional
order_db ichida transaction

payment-service:
@Transactional
payment_db ichida transaction

inventory-service:
@Transactional
inventory_db ichida transaction

Lekin bularni bitta global transaction qilish murakkab va ko‘pincha yomon tanlov.

Shuning uchun distributed system’da ko‘proq quyidagi model ishlatiladi:

Local transaction
+ Event
+ Retry
+ Compensation
+ Idempotency
+ Observability

4. SAGA Pattern

SAGA - uzun biznes transaction’ni bir nechta kichik local transactionlarga bo‘lish patterni.

Har qadam:

local transaction bajaradi
keyingi qadamni chaqiradi yoki event chiqaradi
xato bo‘lsa compensation ishlaydi

Masalan order checkout:

Create Order
   ↓
Reserve Stock
   ↓
Take Payment
   ↓
Create Delivery
   ↓
Complete Order

Agar payment fail bo‘lsa:

Payment failed
   ↓
Release Stock
   ↓
Cancel Order

Bu yerda rollback database rollback emas. Bu compensating action deyiladi.

5. Compensation nima?

Compensation - oldin bajarilgan qadamni biznes jihatdan bekor qilish.

Misollar:

Muhim:

Compensation har doim real rollback emas. Masalan payment refund qilinsa, pul darhol qaytmasligi mumkin. Lekin biznes holat tuzatiladi.

6. SAGA ikki xil bo‘ladi

1. Choreography
2. Orchestration

7. SAGA Choreography

Choreography’da markaziy boshqaruvchi yo‘q. Har service event eshitadi va o‘z ishini qiladi.

Flow:

OrderCreatedEvent
        ↓
Inventory service stock reserve qiladi
        ↓
StockReservedEvent
        ↓
Payment service pul oladi
        ↓
PaymentCompletedEvent
        ↓
Delivery service delivery yaratadi
        ↓
DeliveryCreatedEvent
        ↓
Order service orderni CONFIRMED qiladi

Choreography example

order-service:
OrderCreatedEvent publish qiladi

inventory-service:
OrderCreatedEvent eshitadi
StockReservedEvent publish qiladi

payment-service:
StockReservedEvent eshitadi
PaymentCompletedEvent publish qiladi

delivery-service:
PaymentCompletedEvent eshitadi
DeliveryCreatedEvent publish qiladi

Kodda ko‘rinishi:

@Component
class InventoryOnOrderCreated {

    private final InventoryService inventoryService;
    private final ApplicationEventPublisher events;

    @EventListener
    public void on(OrderCreatedEvent event) {
        inventoryService.reserve(event.orderId(), event.items());

        events.publishEvent(new StockReservedEvent(
                event.orderId(),
                event.items()
        ));
    }
}

Choreography afzalliklari

loose coupling
markaziy coordinator yo‘q
service’lar mustaqilroq
event-driven architecture uchun tabiiy
kichik flowlarda yaxshi

Choreography kamchiliklari

flow qayerda tugashini tushunish qiyin
debug qilish murakkab
event chain ko‘payib ketadi
failure handling tarqalib ketadi
business process diagrammasi kodda aniq ko‘rinmaydi

Katta flow’da shunday bo‘lib ketadi:

OrderCreated → StockReserved → PaymentStarted → PaymentCompleted
→ DeliveryCreated → InvoiceGenerated → NotificationSent

Xato qayerda bo‘lganini topish qiyinlashadi.

8. SAGA Orchestration

Orchestration’da bitta markaziy orchestrator flow’ni boshqaradi.

Masalan:

OrderSagaOrchestrator
   ↓
InventoryService.reserve()
   ↓
PaymentService.charge()
   ↓
DeliveryService.create()
   ↓
OrderService.confirm()

Agar payment fail bo‘lsa:

OrderSagaOrchestrator
   ↓
InventoryService.release()
   ↓
OrderService.cancel()

Orchestration misol kod:

@Service
public class OrderSagaOrchestrator {

    private final InventoryClient inventoryClient;
    private final PaymentClient paymentClient;
    private final DeliveryClient deliveryClient;
    private final OrderService orderService;

    public void process(Long orderId) {
        try {
            inventoryClient.reserve(orderId);
            paymentClient.charge(orderId);
            deliveryClient.create(orderId);
            orderService.confirm(orderId);
        } catch (PaymentFailedException ex) {
            inventoryClient.release(orderId);
            orderService.cancel(orderId);
        }
    }
}

Bu soddalashtirilgan. Production’da retry, timeout, state machine, event log, idempotency kerak bo‘ladi.

Orchestration afzalliklari

business flow bitta joyda ko‘rinadi
debug qilish osonroq
compensation tartibli
murakkab processlar uchun yaxshi
monitoring qilish oson

Orchestration kamchiliklari

orchestrator ko‘p narsani biladi
coupling kuchayishi mumkin
orchestrator failure nuqtasi bo‘lishi mumkin
service’lar orasida command-style dependency paydo bo‘ladi

9. Choreography vs Orchestration

Qisqa qoida:

Kichik, oddiy event flow → choreography
Murakkab, ko‘p qadamli biznes process → orchestration

10. Transactional Outbox Pattern

Distributed system’da eng katta muammolardan biri:

Database’ga yozildi, lekin event publish bo‘lmadi.

Masalan:

@Transactional
public void createOrder(CreateOrderCommand command) {
    orderRepository.save(order);

    kafkaTemplate.send("order-created", event);
}

Bu xavfli.

Nima bo‘lishi mumkin?

Order DB’ga yozildi
Kafka publish vaqtida broker down bo‘ldi
Transaction commit bo‘ldi
Lekin event ketmadi
Payment service order borligini bilmadi

Yoki teskarisi:

Kafka event ketdi
DB transaction rollback bo‘ldi
Payment service mavjud bo‘lmagan order uchun payment boshladi

11. Outbox yechimi

Transactional Outbox’da biznes data va event bir xil database transaction’da yoziladi.

orders table
outbox_events table

Transaction:

1. orders table’ga order yoziladi
2. outbox_events table’ga OrderCreated event yoziladi
3. transaction commit

Keyin alohida process outbox’dan eventni brokerga yuboradi.

Outbox table

CREATE TABLE outbox_events (
    id UUID PRIMARY KEY,
    aggregate_type VARCHAR(100) NOT NULL,
    aggregate_id VARCHAR(100) NOT NULL,
    event_type VARCHAR(100) NOT NULL,
    payload JSONB NOT NULL,
    status VARCHAR(30) NOT NULL,
    created_at TIMESTAMP NOT NULL,
    published_at TIMESTAMP
);

Order create

@Transactional
public void createOrder(CreateOrderCommand command) {
    Order order = Order.create(command.customerId(), command.items());

    orderRepository.save(order);

    OutboxEvent event = OutboxEvent.of(
            "Order",
            order.getId().toString(),
            "OrderCreated",
            toJson(new OrderCreatedEvent(order.getId(), order.getTotal()))
    );

    outboxRepository.save(event);
}

Muhim:

Order va OutboxEvent bitta transaction’da commit bo‘ladi.

12. Outbox publisher

Keyin background worker eventlarni publish qiladi:

@Scheduled(fixedDelay = 1000)
public void publishOutboxEvents() {
    List<OutboxEvent> events = outboxRepository.findTop100ByStatus("NEW");

    for (OutboxEvent event : events) {
        kafkaTemplate.send(event.getEventType(), event.getPayload());

        event.markPublished();
        outboxRepository.save(event);
    }
}

Bu oddiy variant. Production’da quyidagilar kerak:

batch processing
locking
retry count
dead-letter status
idempotent publish
ordering
metrics
backpressure

13. Outbox + Debezium CDC

Outbox polling qilish mumkin, lekin katta system’da ko‘pincha CDC ishlatiladi.

CDC - Change Data Capture.

Flow:

Application
   ↓
orders + outbox_events DB’ga yozadi
   ↓
Debezium database transaction log’ni o‘qiydi
   ↓
Outbox row paydo bo‘lganini ko‘radi
   ↓
Kafka’ga event chiqaradi

Architecture:

order-service
   ↓ local transaction
PostgreSQL
   ↓ WAL/binlog
Debezium
   ↓
Kafka topic
   ↓
payment-service

Nima uchun Debezium yaxshi?

application polling qilmaydi
DB transaction log’dan ishonchli o‘qiydi
event yo‘qolish xavfi kamayadi
high-throughput event publishing uchun yaxshi
outbox relay alohida infrastructure bo‘ladi

Lekin complexity oshadi:

Debezium connector setup
Kafka dependency
schema evolution
connector monitoring
offset management
DLQ strategy

14. Outbox pattern nimani kafolatlaydi?

Transactional Outbox shuni kafolatlaydi:

Agar order DB’da bo‘lsa, outbox event ham DB’da bo‘ladi.

Lekin shuni kafolatlamaydi:

consumer eventni faqat bir marta oladi
event duplicate bo‘lmaydi
event doim tartibda keladi
consumer xatosiz ishlaydi

Shuning uchun keyingi pattern kerak:

Idempotent Consumer

15. Idempotent Consumer Pattern

Event-driven system’da bitta event bir necha marta kelishi mumkin.

Sabablar:

producer retry
broker retry
consumer ack bermadi
consumer qayta ishga tushdi
network timeout
outbox relay duplicate publish qildi

Demak consumer shunday yozilishi kerak:

Bitta event 2 marta kelsa ham biznes natija 1 marta bajarilsin.

Bu idempotency deb ataladi.

Yomon consumerga misol:

@KafkaListener(topics = "payment-completed")
public void on(PaymentCompletedEvent event) {
    orderService.markPaid(event.orderId());
    notificationService.sendPaymentSuccess(event.orderId());
}

Agar event 2 marta kelsa:

order ikki marta update bo‘lishi mumkin
notification ikki marta ketishi mumkin
bonus ikki marta yozilishi mumkin

Yaxshi consumer: processed_events table

CREATE TABLE processed_events (
    event_id UUID PRIMARY KEY,
    processed_at TIMESTAMP NOT NULL
);

Consumer:

@Transactional
public void handle(PaymentCompletedEvent event) {
    if (processedEventRepository.existsById(event.eventId())) {
        return;
    }

    orderService.markPaid(event.orderId());

    processedEventRepository.save(new ProcessedEvent(
            event.eventId(),
            Instant.now()
    ));
}

Bu bilan event duplicate kelsa, ikkinchi marta bajarilmaydi.

16. Idempotency key

REST API’da ham idempotency kerak bo‘ladi.

Masalan payment API:

POST /payments
Idempotency-Key: 8f1a-xyz-123

Agar client timeout sabab requestni qayta yuborsa, payment ikki marta olinmasligi kerak.

Table:

CREATE TABLE idempotency_keys (
    key VARCHAR(100) PRIMARY KEY,
    request_hash VARCHAR(255),
    response_body JSONB,
    status VARCHAR(30),
    created_at TIMESTAMP
);

Flow:

1. Request keldi
2. Idempotency-Key tekshirildi
3. Oldin bajarilgan bo‘lsa, eski response qaytarildi
4. Yangi bo‘lsa, operation bajarildi
5. Natija key bilan saqlandi

17. Idempotent Consumer’da muhim qoidalar

event’da unique eventId bo‘lsin
processed_events table transaction ichida yozilsin
business operation va processed marker bitta transaction’da bo‘lsin
side effectlar ehtiyot bilan qilinsin
notification/email ham duplicate-safe bo‘lsin

Yomon:

email yuborildi
keyin processed_events yozishda xato bo‘ldi
event qayta keldi
email yana yuborildi

Yechim:

email ham outbox orqali yuboriladi
yoki notification service idempotent bo‘ladi

18. Distributed Locking

Distributed lock - bir nechta instance bir xil ishni bir vaqtda bajarmasligi uchun lock.

Masalan:

order-service 3 ta podda ishlayapti
har pod scheduled job ishga tushiradi
invoice generation faqat bitta podda ishlashi kerak

Distributed lock kerak bo‘lishi mumkin:

scheduled job faqat bitta instance’da
bir resource’ni bir vaqtda bitta process update qilsin
inventory reservation
leader election
rate-limited external API call

19. Redis/Redisson lock

Spring projectlarda ko‘p ishlatiladigan variant:

RLock lock = redissonClient.getLock("invoice-generation");

boolean acquired = lock.tryLock(5, 30, TimeUnit.SECONDS);

if (!acquired) {
    return;
}

try {
    invoiceService.generateInvoices();
} finally {
    lock.unlock();
}

Bu nimani anglatadi?

5 sekund ichida lock olishga urinadi
lock olinsa 30 sekund lease time
ish tugasa unlock qiladi

20. Distributed lock xavflari

Distributed lock oson ko‘rinadi, lekin xavfli.

Muammolar:

lock olindi, process o‘ldi
lease time noto‘g‘ri tanlandi
network partition
clock drift
long-running job lease’dan uzoq davom etdi
unlock noto‘g‘ri instance’dan qilindi
Redis unavailable bo‘ldi

Qoida:

Distributed lock’ni transaction o‘rniga ishlatmang. U faqat coordination uchun.

21. Database lock alternativasi

Ba’zan DB lock yetarli bo‘ladi.

Masalan PostgreSQL advisory lock:

SELECT pg_try_advisory_lock(12345);

Yoki row-level lock:

SELECT *
FROM jobs
WHERE status = 'NEW'
FOR UPDATE SKIP LOCKED
LIMIT 100;

SKIP LOCKED job processing uchun juda foydali:

bir nechta worker bor
har biri lock bo‘lmagan joblarni oladi
bir job ikki workerga tushmaydi

22. Distributed lock qachon kerak emas?

Ko‘p holatda lock o‘rniga yaxshiroq pattern bor:

Arxitektor qoida:

Lock - oxirgi variantlardan biri. Avval idempotency, queue, database constraint, optimistic locking o‘ylansin.

23. Two-Phase Commit - 2PC

Two-Phase Commit - bir nechta resource orasida distributed transaction qilish usuli.

Masalan:

order_db
payment_db
inventory_db

hammasi bitta global transaction’da commit/rollback bo‘lishi kerak.

2PC ikki bosqich:

1. Prepare phase
2. Commit phase

Coordinator resource’lardan so‘raydi:

"Commit qilishga tayyormisiz?"

Hammasi "ha" desa:

commit

Biri "yo‘q" desa:

rollback

24. 2PC nega yomon?

Nazariy jihatdan chiroyli. Amalda distributed microservice’da ko‘pincha yomon.

Kamchiliklar:

coordinator kerak
resource’lar lock ushlab turadi
latency oshadi
availability pasayadi
network failure’da murakkab holat
service autonomy buziladi
cloud-native architecture’ga mos emas
scaling qiyin

Microservice’da bitta service yiqilsa, butun transaction osilib qolishi mumkin.

25. 2PC qachon ishlatilishi mumkin?

Ba’zi enterprise systemlarda hali ham ishlatiladi:

legacy enterprise app
XA transaction support bor
kam traffic
strong consistency juda muhim
bitta organization ichidagi controlled environment

Lekin zamonaviy cloud-native Spring microservice architecture’da ko‘pincha:

SAGA + Outbox + Idempotency

yaxshiroq.

26. 2PC o‘rniga nima?

27. Consistency turlari

Distributed system’da ko‘pincha eventual consistency qabul qilinadi.

Strong consistency

hamma joy darhol bir xil

Monolith + bitta DB’da osonroq.

Eventual consistency

hozircha order CREATED
bir necha sekunddan keyin PAID
keyin CONFIRMED

Ya’ni system vaqt o‘tib consistent bo‘ladi.

Misol:

Order created
Payment processing
Payment completed
Order confirmed

Foydalanuvchiga status ko‘rsatiladi:

{
  "orderId": 123,
  "status": "PAYMENT_PROCESSING"
}

28. Eventual consistency UX masalasi

Backend eventual consistent bo‘lsa, frontend ham shuni tushunishi kerak.

Yomon UX:

Buyurtma yaratildi, lekin payment hali tugamagan.
Frontend "xato" deb ko‘rsatadi.

Yaxshi UX:

Buyurtma qabul qilindi.
To‘lov tekshirilmoqda.
Statusni yangilab turamiz.

Statuslar:

CREATED
STOCK_RESERVED
PAYMENT_PROCESSING
PAID
CONFIRMED
FAILED
CANCELLED

29. Ordering muammosi

Eventlar noto‘g‘ri tartibda kelishi mumkin:

PaymentCompletedEvent oldin keldi
OrderCreatedEvent keyin keldi

Yoki bir aggregate uchun eventlar tartibi buziladi.

Yechimlar:

Kafka partition key = aggregateId
event version
sequence number
consumer buffering
idempotent state transition

Masalan:

public record OrderEvent(
        UUID eventId,
        Long orderId,
        long version,
        String type,
        Instant occurredAt
) {}

Consumer eski versionni ko‘rsa ignore qiladi.

30. Optimistic locking

Concurrent update uchun distributed lock shart emas. Ko‘p holatda optimistic locking yetarli.

Entity:

@Entity
public class OrderEntity {

    @Id
    private Long id;

    @Version
    private Long version;

    private OrderStatus status;
}

Agar ikki transaction bir orderni update qilsa:

birinchisi yutadi
ikkinchisi OptimisticLockException oladi

Keyin retry yoki business error.

Bu inventory, order status, account update kabi joylarda foydali.

31. Transactional Inbox Pattern

Outbox producer tomonida reliable event publish uchun.

Inbox consumer tomonida reliable event processing uchun.

incoming_events table

Consumer eventni avval inbox’ga yozadi, keyin process qiladi.

Flow:

Kafka event keldi
   ↓
incoming_events table’ga yozildi
   ↓
business processing
   ↓
processed status

Bu ayniqsa complex consumer processing uchun foydali bo'ladi.

32. Dead Letter Queue - DLQ

Agar event qayta-qayta process bo‘lmasa, cheksiz retry qilish yomon.

Yechim:

retry 3 marta
keyin DLQ topic
alert
manual investigation
replay tool

Flow:

payment-events
   ↓
consumer fail
   ↓ retry
consumer fail
   ↓ retry
consumer fail
   ↓
payment-events-dlq

DLQ production’da shart:

xato event yo‘qolmasin
consumer to‘xtab qolmasin
manual fix/replay bo‘lsin

33. Real flow: Order checkout

Production-ready distributed flow:

1. order-service order yaratadi
2. order_db orders + outbox_events yoziladi
3. Debezium outbox eventni Kafka’ga chiqaradi
4. inventory-service OrderCreatedEvent eshitadi
5. inventory stock reserve qiladi
6. inventory outbox StockReservedEvent chiqaradi
7. payment-service StockReservedEvent eshitadi
8. payment idempotency key bilan charge qiladi
9. PaymentCompletedEvent chiqadi
10. order-service eventni idempotent consume qiladi
11. order status CONFIRMED bo‘ladi

Failure case:

payment fail
   ↓
PaymentFailedEvent
   ↓
inventory stock release
   ↓
order status CANCELLED

34. Spring Boot structure

com.company.order
 ├── domain
 │    ├── Order.java
 │    └── OrderStatus.java
 │
 ├── application
 │    ├── CreateOrderHandler.java
 │    ├── ConfirmOrderHandler.java
 │    └── CancelOrderHandler.java
 │
 ├── outbox
 │    ├── OutboxEvent.java
 │    ├── OutboxRepository.java
 │    └── OutboxService.java
 │
 ├── inbox
 │    ├── ProcessedEvent.java
 │    └── ProcessedEventRepository.java
 │
 ├── messaging
 │    ├── OrderEventPublisher.java
 │    └── PaymentCompletedListener.java
 │
 └── web
      └── OrderController.java

35. Eng ko‘p xatolar

Xato 1: @Transactional bilan Kafka publish qilish

@Transactional
public void createOrder() {
    orderRepository.save(order);
    kafkaTemplate.send("order-created", event);
}

Bu atomic emas.

Yaxshiroq:

DB + Outbox bitta transaction
Kafka publish alohida relay/CDC orqali

Xato 2: Consumer idempotent emas

Duplicate event kelganda biznes ikki marta bajariladi.

Xato 3: SAGA’da compensation yo‘q

Flow fail bo‘lsa system yarim holatda qoladi.

Xato 4: Distributed lock bilan hamma narsani yechish

Lock consistency muammolarini to‘liq hal qilmaydi. Ko‘p holatda idempotency va outbox kerak.

Xato 5: 2PC’ni microservice’da default tanlash

Strong consistency xohishi availability va scalability’ni yomonlashtirishi mumkin.

Xato 6: Event schema versioning yo‘q

Event o‘zgarsa consumerlar buziladi.

Yaxshi event:

{
  "eventId": "uuid",
  "eventType": "OrderCreated",
  "eventVersion": 1,
  "occurredAt": "2026-05-21T10:00:00Z",
  "payload": {
    "orderId": 123
  }
}

36. Architect checklist

Distributed data design qilishdan oldin savollar javob berish kerak:

Har service o‘z database’iga egami?
Cross-service transaction bormi?
Failure bo‘lsa compensation qanday?
Event publish reliable bo‘ladimi?
Consumer duplicate eventga tayyormi?
Event ordering kerakmi?
DLQ strategy bormi?
Retry policy qanday?
Business statuslar eventual consistency’ni ko‘rsatadimi?
Observability event flow’ni ko‘rsatadimi?
2PC haqiqatan kerakmi yoki SAGA yetadimi?

37. Qisqa tavsiya

Katta Spring microservice system uchun odatiy stack:

SAGA
+ Transactional Outbox
+ Debezium CDC
+ Kafka
+ Idempotent Consumer
+ DLQ
+ Optimistic Locking
+ Observability

Lock kerak bo‘lsa:

avval database constraint / optimistic lock / queue o‘yla
keyin Redis/Redisson distributed lock

2PC kerak bo‘lsa:

juda ehtiyot bo‘l
cloud-native microservice’da default tanlama

38. Arxitektor xulosasi

Distributed data patterns - distributed system’da "hammasi bitta transaction bo‘lsin" degan fikrdan voz kechib, real failure’larni boshqarish yondashuvi hisoblanadi.

Asosiy formula:

Local transaction
+ Reliable event publishing
+ Idempotent consuming
+ Compensation
+ Retry/DLQ
+ Observability
= production-ready distributed data architecture

Eng muhim qoida:

Distributed system’da failure normal holat. Architecture failure bo‘lmasligiga emas, failure bo‘lganda system to‘g‘ri tiklanishiga quriladi.

Bu blok quyidagilarni o‘z ichiga oladi: Spring Native / GraalVM native image, Spring 6 AOT compilation, reflection hints & proxy hints, native image trade-offlari, va qachon native, qachon JVM tanlash.

1. Muammo nimada?

Oddiy Spring Boot application odatda JVM’da ishlaydi:

Java code
   ↓
Bytecode
   ↓
JVM
   ↓
Runtime classpath scanning
   ↓
Spring context startup
   ↓
Application ready

Spring Boot application start vaqtida ko‘p ish qiladi:

classpath scan
annotation scan
bean definition yaratish
auto-configuration tanlash
reflection ishlatish
proxy yaratish
configuration binding
condition tekshirish

Katta service’da bu startup vaqtini oshiradi.

Masalan:

order-service JVM startup: 5-20 sekund
serverless function cold start: juda sekin
Kubernetes scale-up: pod tez ready bo‘lmaydi

Shu yerda AOT va Native Image yordam beradi.

2. AOT nima?

AOT - Ahead-of-Time processing.

Ya’ni Spring runtime’da qiladigan ayrim ishlarni build vaqtida oldindan bajaradi.

Spring Framework hujjatlarida AOT optimizations ApplicationContextni build vaqtida tekshirib, odatda runtime’da qilinadigan discovery va decision logic’ni oldindan bajarishi aytilgan. Bu startup arrangement’ni soddaroq va aniqroq qiladi. (Home)

Oddiy JVM mode:

Application start bo‘ldi
   ↓
Spring classpath scan qildi
   ↓
Beanlarni topdi
   ↓
Proxy yaratdi
   ↓
Reflection metadata ishlatdi

AOT mode:

Build vaqtida Spring analiz qiladi
   ↓
Bean definitions oldindan tayyorlanadi
   ↓
Reflection/proxy/resource hints generatsiya qilinadi
   ↓
Startup paytida kamroq ish qoladi

3. GraalVM Native Image nima?

GraalVM Native Image Java application’ni JVM bytecode sifatida emas, balki native executable qilib build qiladi.

Ya’ni:

Spring Boot app
   ↓
AOT processing
   ↓
GraalVM native-image
   ↓
Linux/macOS/Windows executable

Natija:

./order-service

Uni ishga tushirish uchun alohida JVM o‘rnatish shart emas.

JVM vs Native Image

4. Spring 6 AOT qanday ishlaydi?

Spring 6 va Spring Boot 3 native image’ni qo‘llash uchun AOT engine bilan keladi.

Build vaqtida Spring quyidagilarni qiladi:

@Configuration classlarni analiz qiladi
@Bean metodlarni ko‘radi
@Component scan natijalarini oldindan hisoblaydi
conditional beanlarni tekshiradi
proxy kerak joylarni aniqlaydi
reflection kerak classlarni ro‘yxatga oladi
resource kerak bo‘lsa qo‘shadi
generated source/code yaratadi

Bu native image uchun muhim, chunki GraalVM build vaqtida iloji boricha hamma narsani bilishi kerak.

5. Native Image nima uchun reflection’dan qo‘rqadi?

Java’da reflection odatda runtime’da ishlaydi:

Class<?> clazz = Class.forName("com.company.Order");
Object obj = clazz.getDeclaredConstructor().newInstance();

JVM buni runtime’da qila oladi.

Lekin native image build qilinayotganda GraalVM shunday savol beradi:

Bu class runtime’da reflection orqali ishlatiladimi?
Constructor kerakmi?
Field kerakmi?
Method kerakmi?
Annotation kerakmi?

Agar oldindan aytilmasa, runtime’da xato chiqishi mumkin.

6. Runtime Hints

Spring’da native image uchun reflection, resource, proxy kabi narsalarni oldindan ko‘rsatish kerak bo‘lsa, RuntimeHints ishlatiladi.

Masalan:

public class OrderRuntimeHints implements RuntimeHintsRegistrar {

    @Override
    public void registerHints(RuntimeHints hints, ClassLoader classLoader) {
        hints.reflection().registerType(
                Order.class,
                MemberCategory.INVOKE_DECLARED_CONSTRUCTORS,
                MemberCategory.INVOKE_PUBLIC_METHODS,
                MemberCategory.DECLARED_FIELDS
        );
    }
}

Keyin config’da ulaymiz:

@ImportRuntimeHints(OrderRuntimeHints.class)
@Configuration
public class OrderNativeConfiguration {
}

Spring Framework hujjatlarida AOT restrictions borligi ko‘rsatiladi: build vaqtidagi optimizatsiya application’ni classpath va environment asosida oldindan belgilangan holatga keltiradi. Shuning uchun runtime’da juda dinamik behavior ishlatish native image’da muammo bo‘lishi mumkin. (Home)

7. Proxy Hints

Spring ko‘p joyda proxy ishlatadi:

@Transactional
@Async
@Cacheable
@Validated
Spring Security method security
AOP

JVM’da proxy runtime’da yaratiladi.

Native image’da esa proxy kerakligini oldindan bilish kerak bo‘ladi.

Masalan interface proxy:

hints.proxies().registerJdkProxy(
        OrderService.class,
        SpringProxy.class,
        Advised.class
);

Ko‘p oddiy Spring holatlarida Spring Boot AOT bularni avtomatik aniqlaydi. Lekin custom AOP, custom reflection yoki third-party library bo‘lsa, qo‘shimcha hint kerak bo‘lishi mumkin.

8. Resource Hints

Agar application runtime’da fayl o‘qisa:

schema.sql
templates/email.html
certificates/public.pem
mapper-config.json

native image ichiga bu resource’larni qo‘shish kerak.

Misol:

public class ResourceHints implements RuntimeHintsRegistrar {

    @Override
    public void registerHints(RuntimeHints hints, ClassLoader classLoader) {
        hints.resources().registerPattern("templates/*.html");
        hints.resources().registerPattern("certificates/*.pem");
    }
}

Aks holda JVM’da ishlagan narsa native’da topilmasligi mumkin.

9. Native Image build qilish

Maven

Odatda Spring Boot native image uchun native profile ishlatiladi:

./mvnw -Pnative native:compile

Yoki container image:

./mvnw -Pnative spring-boot:build-image

Gradle

./gradlew nativeCompile

Natijada executable chiqadi:

target/order-service

yoki:

build/native/nativeCompile/order-service

10. Native application startup

JVM:

java -jar order-service.jar

Native:

./order-service

Native’da startup odatda juda tez bo‘ladi:

JVM:    sekundlar
Native: millisekundlar yoki juda kam sekund

Bu ayniqsa foydali:

serverless functions
CLI tools
short-lived jobs
Kubernetes rapid scale-up
cold start sensitive workloads
edge deployment

11. Native Image trade-offlari

Native image faqat "tezroq" degani emas. Bu trade-off.

GraalVM Native Image optimizatsiya va performance hujjatlarida native executable’ni performance, file size, build time va debuggability kabi metrikalar bo‘yicha sozlash mexanizmlari borligi aytiladi. (GraalVM)

Afzalliklar

startup juda tez
memory footprint ko‘pincha pastroq
JVM kerak emas
container image kichikroq bo‘lishi mumkin
serverless cold start yaxshi
Kubernetes scale-up tezroq

Kamchiliklar

build vaqti uzoq
native build ko‘proq RAM talab qiladi
reflection/proxy/resource muammolari chiqishi mumkin
debug qilish qiyinroq
ba’zi librarylar native’da to‘liq mos emas
peak throughput JVM’dan past bo‘lishi mumkin
dynamic class loading cheklangan

12. Startup vs Throughput

Native image ko‘pincha startup bo‘yicha yutadi.

Lekin uzoq ishlaydigan, juda yuqori throughput talab qiladigan service uchun JVM ba’zida yaxshiroq bo‘lishi mumkin.

Sabab:

JVM JIT compiler runtime’da kodni optimallashtiradi
hot pathlarni aniqlaydi
uzoq ishlagan sari performance yaxshilanishi mumkin

Native image esa oldindan kompilyatsiya qilingan. Startup tez, lekin JVM JIT’ning uzoq muddatli optimizatsiyalari yo‘q.

Arxitektor xulosa:

Native image - har doim JVM’dan tezroq degani emas. U asosan startup va memory bo‘yicha kuchli.

13. Memory masalasi

GraalVM Native Image memory management hujjatlarida native image uchun turli GC implementatsiyalar mavjudligi, Serial GC default ekanligi va u kichik heap hamda past memory footprint uchun optimallashtirilgani ko‘rsatiladi. (Oracle Docs)

Bu serverless yoki kichik containerlarda foydali.

Lekin katta long-running API uchun faqat "native kam RAM yeydi" deb qaror qilish noto‘g‘ri. Har doim real workload bilan benchmark qilish kerak.

14. Native image’da muammo beradigan joylar

Quyidagi narsalar native’da ehtiyot talab qiladi:

Reflection
Dynamic proxy
CGLIB proxy
Dynamic class loading
Serialization/deserialization
Jackson polymorphic mapping
Hibernate lazy proxy
JPA metamodel
Custom annotation scanning
JNI
File/resource loading
Third-party SDK
Scripting engines
Runtime-generated bytecode

Masalan, Jackson DTO’larni reflection orqali ishlatsa, Spring Boot ko‘p holatda hintlarni avtomatik chiqaradi. Lekin custom serializer/deserializer, polymorphic type yoki external SDK bo‘lsa, qo‘lda hint kerak bo‘lishi mumkin.

15. Spring Boot + JPA + Native

JPA native image’da ishlaydi, lekin oddiy REST API’dan murakkabroq.

Sabab:

Hibernate reflection ishlatadi
Entity proxy bor
Lazy loading bor
Annotation metadata kerak

Spring Boot AOT ko‘p narsani hal qiladi. Lekin arxitektor sifatida buni bilish kerak:

Native image’da eng oson workload - oddiy REST, HTTP client, JSON, small service. Eng murakkab workload - reflection-heavy ORM, dynamic library, eski SDK’lar.

16. Qachon GraalVM Native tanlash kerak?

Juda yaxshi mos keladi

Serverless function
CLI application
Short-lived batch job
Small REST microservice
Kubernetes’da tez scale-up kerak bo‘lgan service
Memory limit qattiq bo‘lgan container
Edge service
Internal tool

Masalan:

notification-worker
image-resize-function
pdf-generator-cli
webhook-handler
small-auth-adapter

Ehtiyotkorlik bilan tanlash kerak

katta monolith
og‘ir JPA/Hibernate service
ko‘p reflection ishlatadigan legacy app
ko‘p dynamic plugin ishlatadigan system
yuqori throughput talab qiladigan long-running service
native support’i noaniq third-party SDK

Bu holatda JVM ko‘pincha xavfsizroq.

17. JVM qachon yaxshiroq?

JVM tanlash yaxshi bo‘ladi:

service doim ishlab tursa
startup critical bo‘lmasa
throughput muhim bo‘lsa
JIT optimizatsiya foydali bo‘lsa
debug/profiling muhim bo‘lsa
library ecosystem murakkab bo‘lsa
team native image tajribasiz bo‘lsa

Masalan:

high-traffic payment API
large business monolith
analytics service
complex report generator
legacy integration service

18. Native vs JVM qaror jadvali

19. Arxitektor qaror formulasi

Agar startup + memory muhim bo‘lsa
va application nisbatan statik bo‘lsa
va librarylar native image’ni qo‘llasa
→ GraalVM Native ko‘rib chiqiladi.

Agar service long-running bo‘lsa
va throughput muhim bo‘lsa
va reflection/dynamic behavior ko‘p bo‘lsa
→ JVM yaxshiroq.

20. Spring Native eski nomi haqida

Oldin Spring Native degan alohida project bor edi. Spring Boot 3 va Spring Framework 6 bilan native support asosiy ekotizimga kirib keldi.

Bugungi yondashuv:

Spring Boot 3+
Spring Framework 6+
GraalVM Native Image
AOT processing
Runtime hints

Ya’ni yangi projectlarda alohida eski spring-native projectiga tayanish kerak emas.

21. Production’da tekshirish checklist

Native image’ni production’ga chiqarishdan oldin quyidagilar tekshiriladi:

Application native build bo‘ladimi?
Barcha endpointlar ishlaydimi?
JSON serialization/deserialization to‘g‘rimi?
Validation ishlaydimi?
Security filter chain ishlaydimi?
JPA queries ishlaydimi?
Migration tool ishlaydimi?
Kafka/Rabbit listener ishlaydimi?
Actuator health/metrics ishlaydimi?
SSL/certificate/resource fayllar topiladimi?
Container image size va startup o‘lchandimi?
Memory usage real load’da tekshirildimi?
Throughput JVM bilan solishtirildimi?

Eng muhim qism:

Native image qarori benchmark bilan qilinadi, taxmin bilan emas.

22. Oddiy native-ready coding qoidalari

1. Runtime’da class nomidan object yaratishni kamaytirish

Yomon:

Class<?> clazz = Class.forName(className);
Object instance = clazz.getDeclaredConstructor().newInstance();

Yaxshi:

Map<String, PaymentHandler> handlers;

2. Reflection ishlatsangiz hint bering

@ImportRuntimeHints(PaymentRuntimeHints.class)
@Configuration
class PaymentNativeConfig {
}

3. Resource fayllarni aniq ko‘rsating

hints.resources().registerPattern("templates/*.html");

4. Third-party library native support’ini tekshiring

Agar SDK eski bo‘lsa, native image’da muammo ko‘p bo‘lishi mumkin.

5. CI’da native build qo‘shing

Faqat local’da emas, CI’da ham native build ishlashi kerak:

pull request
   ↓
unit tests
   ↓
integration tests
   ↓
nativeCompile
   ↓
native smoke test

23. Real misol: webhook service

Webhook service:

request qabul qiladi
signature tekshiradi
eventni Kafka’ga yozadi
tez javob qaytaradi

Bu native uchun yaxshi nomzod:

kichik service
startup muhim
memory kam
logic oddiy
reflection kam

Architecture:

webhook-service native image
   ↓
Kubernetes’da tez start
   ↓
autoscaling tezroq
   ↓
cold start kamroq

24. Real misol: katta ERP monolith

ERP monolith:

500+ entity
Hibernate complex mapping
dynamic report engine
reflection-heavy library
ko‘p scheduled job
legacy SDK

Bu native uchun xavfli nomzod.

Yaxshiroq qaror:

JVM’da qoldirish
startup optimizatsiya qilish
lazy initialization tekshirish
container memory tuning
JVM/CDS ko‘rib chiqish

25. Eng ko‘p xatolar

Xato 1: Native image’ni silver bullet deb o‘ylash

Native image hamma muammoni hal qilmaydi.

U asosan:

startup
memory
cold start

muammolarini hal qiladi.

Xato 2: Benchmark qilmasdan qaror qilish

To‘g‘ri test:

startup time
RSS memory
heap usage
CPU
p95/p99 latency
throughput
container image size
build time

JVM va native ikkalasi bir xil load’da solishtiriladi.

Xato 3: Library compatibility tekshirmaslik

Agar critical SDK native image’da ishlamasa, production risk katta.

Xato 4: Native build’ni CI’ga qo‘shmaslik

Local’da ishlagan native build keyin dependency update’dan buzilishi mumkin.

Xato 5: Reflection hintlarni tartibsiz yozish

Keraksiz ko‘p hint native image size va attack surface’ni oshirishi mumkin.

26. Arxitektor xulosasi

GraalVM Native & AOT - Spring Boot application’ni tezroq start qiladigan, ko‘pincha kamroq memory ishlatadigan native executable ko‘rinishida chiqarish imkonini beradi.

Lekin arxitektor qarori bunday bo‘ladi:

Native image kerakmi?
Startup haqiqatan muhimmi?
Memory haqiqatan muhimmi?
Build pipeline bunga tayyormi?
Librarylar mosmi?
Team support qila oladimi?
JVM bilan benchmark qildikmi?

Eng muhim qoida:

GraalVM Native - performance strategiya emas, deployment va startup strategiya. Uni to‘g‘ri workload uchun ishlatish kerak.

Qisqa tavsiya:

Serverless, CLI, short-lived job, small microservice → Native yaxshi.
Katta long-running, throughput-heavy, reflection-heavy service → JVM ko‘pincha yaxshi.

Qaysi framework yaxshi?

emas.

Asosiy savol:

Kompaniya 2-5 yil davomida Java/Spring ekotizimini qanday boshqaradi?
Qaysi texnologiya standart bo‘ladi?
Qaysi versiyalar support qilinadi?
Architecture qoidalarini kim va qanday nazorat qiladi?
API contractlar qanday boshqariladi?
Developerlar uchun platforma qanchalik qulay?

Bu mavzu quyidagilarni o‘z ichiga oladi: Spring Boot vs Quarkus vs Micronaut tanlash, Spring release cadence & EOL planning, ArchUnit - architecture-as-tests, OpenAPI-first contract governance, Developer Experience, va Inner-source starter contribution model.

1. Tech Strategy nima?

Tech strategy - kompaniya yoki katta team qaysi texnologiyalarni tanlashi, qaysilarini cheklashi, qaysilariga investitsiya qilishi haqida qarorlar to‘plami.

Masalan:

Backend framework: Spring Boot
Java version: 21 LTS
Build tool: Gradle yoki Maven
API contract: OpenAPI-first
Messaging: Kafka
Database: PostgreSQL
Cache: Redis
Observability: Micrometer + Prometheus + Grafana
Security: OAuth2/OIDC
Container: Kubernetes

Bu qarorlar yozib qo‘yilmasa, har team o‘zicha tanlaydi:

Team A → Spring Boot
Team B → Quarkus
Team C → Micronaut
Team D → Node.js
Team E → eski Spring MVC

Bunday erkinlik ba’zida foydali, lekin katta kompaniyada maintenance xarajatini oshiradi.

2. Governance nima?

Governance - tanlangan texnik standartlar haqiqatan ham bajarilishini ta’minlash.

Faqat hujjat yozish yetmaydi.

Yomon governance:

README’da "Controller repository chaqirmasin" deb yozilgan.
Lekin CI’da tekshiruv yo‘q.

Yaxshi governance:

Architecture rule ArchUnit test bilan tekshiriladi.
OpenAPI spec CI’da lint qilinadi.
Dependency version BOM orqali boshqariladi.
Security baseline starter orqali majburiy ulanadi.

Ya’ni governance:

standard + automation + review + feedback + measurement

3. Spring Boot vs Quarkus vs Micronaut

Arxitektor framework tanlaganda faqat benchmark bilan qaror qilmaydi. Quyidagilarni solishtiradi:

team tajribasi
ecosystem
documentation
library compatibility
cloud-native support
native image support
startup/memory
enterprise support
hiring market
long-term maintenance
integrationlar

Spring Boot

Spring Boot - Java enterprise ekotizimida eng keng ishlatiladigan variantlardan biri.

Kuchli tomonlari:

juda katta ecosystem
Spring Security, Data, Cloud, Batch, Integration
ko‘p developer biladi
documentation kuchli
enterprise support kuchli
legacy va modern systemlarga mos
production patternlar ko‘p

Kamchiliklari:

startup/memory Quarkus/Micronaut’dan og‘irroq bo‘lishi mumkin
magic/auto-configuration ko‘p
noto‘g‘ri ishlatilsa monolith tez chalkashadi
native image uchun ba’zi dynamic librarylar muammo berishi mumkin

Spring Boot uchun rasmiy support policy’da major versiyalar kamida 3 yil, minor versiyalar kamida 12 oy support qilinishi ko‘rsatilgan; bu EOL planning uchun muhim. (GitHub)

Quarkus

Quarkus cloud-native va Kubernetes-native Java uchun optimallashtirilgan framework sifatida ko‘riladi.

Kuchli tomonlari:

fast startup
low memory footprint
GraalVM native image bilan yaxshi integratsiya
Kubernetes/cloud-native use case’lar uchun qulay
developer live reload tajribasi yaxshi

Kamchiliklari:

Spring ekotizimidan chiqish xarajati bor
team learning curve kerak
hamma Spring library patternlari to‘g‘ridan-to‘g‘ri mos emas
enterprise’da Spring kabi universal adoption bo‘lmasligi mumkin

Micronaut

Micronaut ham cloud-native va reflection’ni kamaytirishga qaratilgan framework.

Kuchli tomonlari:

compile-time dependency injection
tez startup
kamroq reflection
serverless va microservice uchun mos
native image use case’lari yaxshi

Kamchiliklari:

Spring’dan migration xarajati bor
ecosystem kichikroq
team tajribasi kerak
ba’zi enterprise integratsiyalar Spring’dagi kabi keng bo‘lmasligi mumkin

4. Framework tanlash qaror jadvali

Arxitektor qoidasi:

Framework tanlash "qaysi biri tezroq?" emas, "qaysi biri bizning team, product, infra va 3 yillik maintenance modelimizga mos?" degan savol bilan qilinadi.

5. Spring Release Cadence & EOL Planning

Spring ekotizimida release va support muddatlarini boshqarish juda muhim.

Agar kompaniyada 30 ta service bo‘lsa, ularning har biri turli Spring Boot versiyada qolib ketsa:

service-a → Spring Boot 2.7
service-b → Spring Boot 3.1
service-c → Spring Boot 3.3
service-d → Spring Boot 3.5

Upgrade, CVE patch, compatibility va support muammoga aylanadi.

Spring Boot support policy’ga ko‘ra major versiyalar kamida 3 yil, minor versiyalar kamida 12 oy support qilinadi; demak Arxitektor har service qaysi supported line’da ekanini kuzatishi kerak. (GitHub)

EOL planning nima?

EOL - End of Life. Versiya public OSS supportdan chiqsa, security fix va bug fix olish qiyinlashadi.

Arxitektor quyidagi matrix yuritadi:

EOL governance qoidasi

1. Har service inventory qilinadi.
2. Java/Spring/Cloud versiyalar yoziladi.
3. EOL sanalar kuzatiladi.
4. EOL’dan 6 oy oldin migration plan boshlanadi.
5. Critical CVE bo‘lsa emergency upgrade process ishlaydi.
6. Company BOM orqali versiyalar markazlashtiriladi.

Bu platform standardization bilan bog‘liq.

6. Architecture-as-Tests

Architecture faqat diagrammada qolmasligi kerak.

Yomon holat:

Diagrammada:
Controller → Service → Repository

Kodda:
Controller → Repository
Service → Controller
Order module → payment.internal.PaymentService

Yaxshi holat:

Architecture rule CI’da test qilinadi.
Qoidani buzgan PR merge bo‘lmaydi.

ArchUnit Java bytecode’ni analiz qilib package, class, layer, cyclic dependency kabi architecture qoidalarini test qilishga imkon beradi. (ArchUnit)

ArchUnit misollar

Controller repository chaqirmasin

@AnalyzeClasses(packages = "com.company")
class ArchitectureTest {

    @ArchTest
    static final ArchRule controllers_should_not_access_repositories =
            noClasses()
                    .that().resideInAPackage("..controller..")
                    .should().accessClassesThat()
                    .resideInAPackage("..repository..");
}

Domain layer Spring’ga qaram bo‘lmasin

@ArchTest
static final ArchRule domain_should_not_depend_on_spring =
        noClasses()
                .that().resideInAPackage("..domain..")
                .should().dependOnClassesThat()
                .resideInAnyPackage("org.springframework..");

Bu Hexagonal/DDD uchun juda foydali.

Internal package tashqaridan ishlatilmasin

@ArchTest
static final ArchRule internal_packages_should_not_be_accessed =
        noClasses()
                .that().resideOutsideOfPackage("..payment..")
                .should().accessClassesThat()
                .resideInAPackage("..payment.internal..");

Cyclic dependency bo‘lmasin

@ArchTest
static final ArchRule modules_should_be_free_of_cycles =
        slices()
                .matching("com.company.(*)..")
                .should()
                .beFreeOfCycles();

7. Architecture governance qoidalari

Arxitektor barcha qoidani birdan majburlamaydi. Bosqichma-bosqich qiladi:

Level 1: Package cycle yo‘q
Level 2: Controller → Service → Repository qoidasi
Level 3: Domain Spring’dan mustaqil
Level 4: Module internal boundary
Level 5: Hexagonal port/adapter dependency direction

Yomon governance:

100 ta ArchUnit rule yozildi.
Team nima uchunligini tushunmadi.
Hamma testni disable qildi.

Yaxshi governance:

Kam, lekin muhim rule.
Har rule sababi yozilgan.
Violation message tushunarli.
Exception process bor.

8. OpenAPI-first Contract Governance

OpenAPI-first - avval API contract yoziladi, keyin implementation yoziladi.

OpenAPI Specification HTTP API’larni standart formatda tasvirlaydi, shunda insonlar va kompyuterlar API imkoniyatlarini source code yoki qo‘shimcha dokumentatsiyasiz tushunishi mumkin. (Swagger) OpenAPI Initiative ham OpenAPI specification API’larni formal standartda tasvirlashini va client code, testlar hamda design standards uchun ishlatilishini ko‘rsatadi. (OpenAPI Initiative)

Code-first vs API-first

Code-first

Controller yoziladi
Swagger avtomatik generate bo‘ladi
Keyin frontend ko‘radi

Afzallik:

tez
kichik project uchun qulay

Kamchilik:

API design tasodifiy chiqadi
breaking change sezilmaydi
consumerlar kech xabar topadi

API-first

OpenAPI spec yoziladi
Review qilinadi
Lint qilinadi
Mock server chiqadi
Client code generate bo‘ladi
Backend implementation specga mos yoziladi

Afzallik:

contract oldindan kelishiladi
frontend/backend parallel ishlaydi
breaking change CI’da topiladi
API governance kuchli bo‘ladi

9. OpenAPI governance da nima tekshiriladi?

CI pipeline’da quyidagilar tekshiriladi:

endpoint naming convention
HTTP method to‘g‘ri ishlatilganmi
error response standartmi
pagination standartmi
auth scopes bor-mi
operationId unique-mi
request/response schema aniqmi
breaking change bormi
deprecated endpoint policy bormi

Masalan naming convention:

GET /orders
POST /orders
GET /orders/{orderId}
PATCH /orders/{orderId}
DELETE /orders/{orderId}

Yomon:

GET /getOrders
POST /createOrder
POST /deleteOrder

Standard error response

OpenAPI’da hamma service bir xil error format ishlatadi:

components:
  schemas:
    ApiError:
      type: object
      required:
        - type
        - message
        - traceId
      properties:
        type:
          type: string
        message:
          type: string
        traceId:
          type: string

Bu frontend va integratsiyalar uchun juda muhim.

10. API compatibility governance

Breaking change oldindan topilishi kerak.

Breaking change misollar:

field remove
field rename
required field qo‘shish
response type o‘zgartirish
HTTP status o‘zgartirish
enum value o‘chirish
endpoint o‘chirish
auth scope o‘zgartirish

CI’da OpenAPI diff ishlatiladi:

old openapi.yml
        ↓ compare
new openapi.yml
        ↓
breaking change bormi?

Agar breaking change bo‘lsa:

major version kerak
deprecation policy kerak
consumer approval kerak

11. Developer Experience - DX

DX - Developer Experience. Platform va governance developerga yordam berishi kerak, to‘sqinlik emas.

Yomon DX:

starter magic qiladi, lekin dokumentatsiya yo‘q
CI xatosi tushunarsiz
project yaratish 3 kun
local environment og‘ir
dependency upgrade qo‘lda
API standard ko‘p, lekin sample yo‘q

Yaxshi DX:

project template tayyor
starterlar dokumentatsiyali
local docker-compose bor
test utilities bor
sample service bor
clear error message bor
migration guide bor
CLI yoki portal bor

Platform team product sifatida ishlashi kerak

Platform team developerlarni "foydalanuvchi" deb ko‘rishi kerak.

Ya’ni platform:

developerga tezroq service yaratishga yordam beradi
security va observabilityni default qiladi
boilerplate kamaytiradi
upgrade’ni osonlashtiradi

Agar governance faqat taqiq bo‘lsa, teamlar workaround qiladi.

12. Developer portal

Katta kompaniyada quyidagi developer portali bo'lishi foydali:

service catalog
owner information
runbook
API documentation
dependency version
SLO/SLA
deployment status
logs/metrics links
on-call info

Masalan service catalog:

Bu incident va governance uchun juda foydali hisoblanadi.

13. Inner-source starter contribution model

Oldingi mavzuda company starterlar haqida gapirdik:

company-security-starter
company-observability-starter
company-web-starter
company-error-starter
company-bom

Inner-source degani - kompaniya ichidagi platform library’lar open-source kabi yuritiladi:

public internal repository
README
issues
pull requests
code owners
release notes
versioning
contribution guide

Nega kerak?

Agar starterlarni faqat platform team o‘zgartira olsa:

product teamlar kutib qoladi
platform bottleneck bo‘ladi
real ehtiyojlar sekin qo‘shiladi

Inner-source modelda:

product team PR ochadi
platform team review qiladi
standartga mos bo‘lsa merge qiladi
release qilinadi
hamma team foydalanadi

Inner-source repository structure

company-platform
 ├── company-bom
 ├── company-web-starter
 ├── company-security-starter
 ├── company-observability-starter
 ├── company-test-starter
 ├── docs
 │    ├── getting-started.md
 │    ├── migration-guide.md
 │    └── contribution-guide.md
 └── examples
      ├── simple-rest-service
      ├── kafka-consumer-service
      └── modulith-service

14. Starter contribution qoidalari

Har PR uchun tekshiruv:

Backward compatible-mi?
Default behavior buzilmaydimi?
Override qilish mumkinmi?
Documentation bor-mi?
Test bor-mi?
Migration note bor-mi?
Security impact bormi?
Observability impact bormi?

Yomon starter change:

company-security-starter yangi versiyada hamma /actuator endpointlarni yopdi
teamlar production’da health check fail oldi

Yaxshi process:

breaking change bo‘lsa major version
release notes
migration guide
sample update
pilot service’da test

15. Technology Radar

Arxitektor organization uchun Technology Radar yuritishi mumkin.

Kategoriyalar:

Adopt
Trial
Assess
Hold

Misol:

Bu teamlarga aniq signal beradi.

16. ADR - Architecture Decision Records

Tech governance’da har muhim qaror yozib boriladi.

ADR structure:

Title
Status
Context
Decision
Consequences
Alternatives
Date
Owner

Misol uchun:

ADR-004: Use Spring Boot as default backend framework

Status: Accepted

Context:
Company’da Java team kuchli, mavjud service’lar Spring’da,
security/data/cloud integratsiyalar ko‘p.

Decision:
New backend services default Spring Boot 3.5 + Java 21 bilan yaratiladi.

Consequences:
Spring ecosystem bo‘yicha platform starterlar yuritiladi.
Quarkus/Micronaut faqat maxsus cold-start use case’da approval bilan.

ADR foydasi:

qaror sababi yo‘qolmaydi
yangi developerlar tushunadi
keyin qarorni qayta ko‘rib chiqish oson

17. Governance review board

Katta organization’da architecture review board bo‘lishi mumkin, lekin ehtiyot bo‘lish kerak.

Yomon review board:

hamma qarorni sekinlashtiradi
approval by bureaucracy
teamlar kutib qoladi

Yaxshi review board:

high-risk qarorlarni ko‘radi
standartlarni yangilaydi
exceptionlarni boshqaradi
teamlarga maslahat beradi
platformni yaxshilaydi

Review kerak bo‘ladigan holatlar:

yangi framework tanlash
yangi database tanlash
public API breaking change
security baseline’dan chetga chiqish
multi-region architecture
critical data migration

18. Exception process

Har doim ham standard 100% mos kelmaydi.

Masalan:

default Spring Boot, lekin serverless function uchun Quarkus kerak
default PostgreSQL, lekin time-series data uchun TimescaleDB kerak
default REST, lekin streaming uchun gRPC kerak

Exception process:

1. Team sabab yozadi
2. Risk va alternativalar ko‘rsatiladi
3. Arxitektor review qiladi
4. Muddat yoki scope belgilanadi
5. ADR yoziladi
6. Ownership aniq bo‘ladi

Bu innovation’ni o‘ldirmaydi, lekin tartibsizlikni kamaytiradi.

19. Metrics for governance

Governance o‘lchanishi kerak.

Quyidagi metrikalar foydali:

nechta service supported Spring Boot versiyada
nechta service EOL riskda
critical CVE count
mean time to patch
starter adoption rate
OpenAPI lint pass rate
architecture test failure trend
new service creation time
deployment frequency
rollback frequency
incident count by category

Masalan:

EOL riskdagi service’lar: 12 → 3
Yangi service yaratish vaqti: 2 kun → 30 daqiqa
Critical CVE patch time: 14 kun → 2 kun

Bu platform strategy foyda berayotganini ko‘rsatadi.

20. Tech debt governance

Arxitektor tech debt’ni ham boshqaradi.

Tech debt turlari:

old Spring Boot version
unsupported Java version
manual security config
missing tests
no OpenAPI spec
no observability
shared database coupling
cyclic package dependencies
legacy authentication

Tech debt backlog:

21. Security governance

Tech strategy’da security baseline bo‘lishi shart:

OAuth2/OIDC standard
JWT validation rules
mTLS kerak joylar
secret management
dependency scanning
container scanning
SAST/DAST
least privilege
audit logging
security headers

Security governance starter orqali ham qo‘llanadi:

company-security-starter
default SecurityFilterChain
standard CORS
standard headers
actuator protection
scope mapping

22. Data governance

Backend architecture’da data governance ham muhim:

PII qayerda saqlanadi?
audit log qayerda?
retention policy qanday?
backup/restore SLA qanday?
data residency bormi?
schema ownership kimda?
shared database mumkinmi?

Microservice’da ayniqsa:

service owns its database
boshqa service DB’ga to‘g‘ridan-to‘g‘ri kirmaydi
data sharing event/API orqali bo‘ladi

23. Platform maturity model

Platform va governance birdan mukammal bo‘lmaydi.

Level 1 - Ad hoc

har team o‘zicha
standard yo‘q
dependencylar chalkash

Level 2 - Documented

standartlar bor
lekin avtomatlashtirilmagan

Level 3 - Automated

starterlar
BOM
CI checks
ArchUnit
OpenAPI lint

Level 4 - Self-service

developer portal
service template
automatic provisioning
dashboardlar

Level 5 - Optimized

metrics-driven governance
automatic dependency PR
policy-as-code
platform product management

Arxitektor maqsadi - organization’ni bosqichma-bosqich yuqoriga olib chiqishdir.

24. Real organization strategy misoli

Aytaylik kompaniyada 25 ta Spring service bor.

Muammo

7 ta service Spring Boot 2.7
10 ta service Spring Boot 3.2
8 ta service Spring Boot 3.5
security config har xil
OpenAPI spec yo‘q
log format har xil
dependency CVE ko‘p

Strategy

1. Service inventory qilinadi
2. Java 21 + Spring Boot 3.5 target belgilanadi
3. Company BOM yaratiladi
4. Security/observability starter majburiy bo‘ladi
5. OpenAPI-first yangi API’lar uchun standard bo‘ladi
6. ArchUnit baseline testlar qo‘shiladi
7. EOL riskdagi service’lar migration plan oladi
8. Developer portalda service catalog yuritiladi

Natija

upgrade boshqariladi
CVE patch tezlashadi
service yaratish osonlashadi
API design bir xil bo‘ladi
architecture erosion kamayadi

25. Eng ko‘p xatolar

Xato 1: Governance’ni faqat taqiq deb tushunish

Yomon:

Buni ishlatma.
Buni tanlama.
Bu mumkin emas.

Yaxshi:

Mana standard.
Mana starter.
Mana template.
Mana exception process.
Mana sample.

Xato 2: Framework tanlashni benchmark bilan tugatish

Benchmark muhim, lekin yetarli emas.

Kerakli savollar:

Team buni biladimi?
Hiring osonmi?
Security integration bormi?
Monitoring bormi?
3 yildan keyin kim support qiladi?

Xato 3: EOL planning yo‘q

Service ishlayapti, lekin unsupported versiyada qolib ketadi.

Xato 4: Architecture rule faqat diagrammada

Diagramma chiroyli, kod esa boshqa. ArchUnit yoki shunga o‘xshash testlar kerak.

Xato 5: API contract governance yo‘q

Har service har xil response, error, pagination, auth style ishlatadi.

Xato 6: Platform team bottleneck bo‘lib qoladi

Inner-source model bo‘lmasa, product teamlar platformni aylanib o‘tadi.

26. Architect checklist

Tech strategy & governance uchun savollar:

Default backend framework nima?
Exception process bormi?
Java/Spring version matrix bormi?
EOL sanalar kuzatiladimi?
Company BOM bormi?
Security starter bormi?
Observability starter bormi?
Architecture tests bormi?
OpenAPI-first qayerda majburiy?
Breaking change qanday aniqlanadi?
Developer portal yoki service catalog bormi?
Platform starterlarga product team PR bera oladimi?
ADR yoziladimi?
Tech debt kim kuzatadi?

27. Qisqa qoida

Tech strategy - nima tanlashni belgilaydi.
Governance - tanlangan narsalar bajarilishini ta’minlaydi.
Platform - developerga buni oson qiladi.
Automation - qoidani real qiladi.
DX - teamlar buni qabul qilishini ta’minlaydi.

28. Arxitektor xulosasi

Tech strategy & governance - Arxitektor’ning eng muhim mas’uliyatlaridan biri. Bu mavzu kod yozishdan ham kengroqdur:

framework tanlash
release/EOL rejalash
dependency boshqarish
security baseline
API contract standard
architecture-as-tests
developer experience
inner-source platform model

Eng muhim qoida:

Governance developerlarni sekinlashtirish uchun emas, katta systemni xavfsiz, izchil va tez rivojlantirish uchun kerak.

Yaxshi tech governance natijasi quyidagicha:

yangi service tez yaratiladi
dependencylar boshqariladi
security default bo‘ladi
API’lar bir xil chiqadi
architecture buzilishi CI’da ushlanadi
upgrade va CVE patchlar rejalangan bo‘ladi
developerlar platformdan qochmaydi, foydalanadi

1. Spring Internals nima?

Spring Internals - bu Spring ichkarida qanday ishlashini tushunish.

Boshlang'ich darajada biz odatda shuni bilamiz:

@Service
public class UserService {
}

Spring buni avtomatik topadi, obyekt yaratadi va kerakli joyga inject qiladi.

O'rta darajada savol boshqacha bo‘ladi:

Spring bu classni qayerdan topdi?
Qachon obyekt yaratdi?
Qachon dependency inject qildi?
Qachon proxy yaratdi?
Qachon @Transactional, @Async, @Cacheable ishlay boshladi?

Mana shu ichki mexanizmlar Spring Internals deyiladi.

2. Eng asosiy tushuncha: IoC Container

Springning yuragi - IoC Container.

IoC - Inversion of Control.

Oddiy Java’da obyektni o‘zingiz yaratamiz:

UserRepository repository = new UserRepository();
UserService service = new UserService(repository);

Spring’da esa obyektlarni Spring yaratadi:

@Service
public class UserService {

    private final UserRepository repository;

    public UserService(UserRepository repository) {
        this.repository = repository;
    }
}

Bu yerda biz new UserRepository() demadingiz. Spring o‘zi yaratdi va constructor orqali berdi.

Spring containerning vazifalari:

3. Bean nima?

Bean - Spring container boshqarayotgan obyekt.

Masalan:

@Service
public class PaymentService {
}

Bu oddiy Java class emas. Spring uni ko‘rib:

"Bu classni men boshqaraman"

deydi va undan bean yaratadi.

Yana bir misol:

@Configuration
public class AppConfig {

    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

Bu yerda RestTemplate ham Spring bean bo‘ladi.

4. Bean lifecycle nima?

Bean lifecycle - Spring bean yaratilganidan to yo‘q qilinishigacha bo‘lgan jarayon.

Soddalashtirilgan tartib:

1. Class topiladi
2. BeanDefinition yaratiladi
3. Bean obyekti yaratiladi
4. Dependency injection bo‘ladi
5. Aware interface’lar chaqiriladi
6. BeanPostProcessor oldingi bosqichi ishlaydi
7. Init method ishlaydi
8. BeanPostProcessor keyingi bosqichi ishlaydi
9. Bean tayyor bo‘ladi
10. App yopilganda destroy method ishlaydi

Keling, buni tushunarliroq qilamiz.

5. BeanDefinition nima?

Spring avval beanni darrov yaratmaydi. Avval uning rejasini tuzadi.

Bu reja BeanDefinition deyiladi.

BeanDefinition ichida shunday ma’lumotlar bo‘ladi:

Misol:

@Service
public class UserService {
}

Spring buni scan qiladi va ichkarida taxminan shunday reja tuzadi:

beanName = "userService"
beanClass = UserService
scope = singleton
lazyInit = false

6. Bean lifecycle oddiy misol

@Component
public class ReportService {

    public ReportService() {
        System.out.println("1. Constructor ishladi");
    }

    @PostConstruct
    public void init() {
        System.out.println("2. Init ishladi");
    }

    @PreDestroy
    public void destroy() {
        System.out.println("3. Destroy ishladi");
    }
}

Natija:

1. Constructor ishladi
2. Init ishladi

Application yopilganda:

3. Destroy ishladi

Bu nimani anglatadi?

constructor - obyekt yaratilayotgan payt.

@PostConstruct - dependencylar inject qilingandan keyin.

@PreDestroy - Spring container yopilayotganda.

7. Constructor va @PostConstruct farqi

Ko‘pchilik shu joyda adashadi.

Constructor

public ReportService(UserRepository repository) {
    this.repository = repository;
}

Constructor asosan:

• majburiy dependencylarni olish uchun;

• obyektni valid holatga keltirish uchun;

• oddiy fieldlarni tayyorlash uchun.

@PostConstruct

@PostConstruct
public void init() {
    // bean to‘liq tayyor bo‘lgandan keyingi ish
}

@PostConstruct:

• dependency injection tugagandan keyin ishlaydi;

• Spring beanni yaratib bo‘lgandan keyin chaqiriladi;

• og‘ir ishlar uchun emas.

Yomon amaliyot:

@PostConstruct
public void init() {
    // DB dan 1 million data o‘qish
    // tashqi API ga request yuborish
    // katta cache warmup qilish
}

Bu startupni sekinlashtiradi.

Yaxshi amaliyot:

@PostConstruct
public void validateConfig() {
    if (apiKey == null || apiKey.isBlank()) {
        throw new IllegalStateException("API key required");
    }
}

8. BeanPostProcessor nima?

BeanPostProcessor - bean yaratilgandan keyin unga aralashish imkonini beradigan mexanizm.

Spring ichida juda ko‘p narsalar aynan shu orqali ishlaydi.

Masalan:

• @Autowired

• @PostConstruct

• AOP proxy

• @Async

• @Transactional

• @Cacheable

Soddalashtirilgan ko‘rinish:

@Component
public class MyBeanPostProcessor implements BeanPostProcessor {

    @Override
    public Object postProcessBeforeInitialization(
            Object bean,
            String beanName
    ) {
        System.out.println("Before init: " + beanName);
        return bean;
    }

    @Override
    public Object postProcessAfterInitialization(
            Object bean,
            String beanName
    ) {
        System.out.println("After init: " + beanName);
        return bean;
    }
}

Bu har bir bean uchun ishlaydi.

9. BeanPostProcessor qayerda ishlatiladi?

Masalan, bizda shunday service bor:

@Service
public class OrderService {

    @Transactional
    public void createOrder() {
        // order yaratish
    }
}

Spring OrderServiceni oddiy obyekt sifatida ishlatib qo‘ymaydi. Unga proxy o‘raydi.

Taxminan:

OrderService original bean
        ↓
Transactional proxy
        ↓
Application ishlatadigan bean

Shuning uchun @Transactional ishlaydi.

Ya’ni biz chaqiramiz:

orderService.createOrder();

Lekin real chaqiruv:

Proxy → transaction start → method → transaction commit/rollback

Mana shu proxy yaratish jarayonlarida BeanPostProcessor muhim rol o‘ynaydi.

10. BeanFactoryPostProcessor nima?

BeanPostProcessor bean obyektiga ta’sir qiladi.

BeanFactoryPostProcessor esa bean yaratilishidan oldin, BeanDefinitionlarga ta’sir qiladi.

Farqi:

Misol:

@Component
public class MyBeanFactoryPostProcessor implements BeanFactoryPostProcessor {

    @Override
    public void postProcessBeanFactory(
            ConfigurableListableBeanFactory beanFactory
    ) {
        System.out.println("Bean definitions count: "
                + beanFactory.getBeanDefinitionCount());
    }
}

Bu kod beanlar yaratilishidan oldin ishlaydi.

11. @Conditional nima?

@Conditional - ma’lum shart bajarilsagina bean yaratish mexanizmi.

Masalan:

@Bean
@ConditionalOnProperty(
        name = "payment.provider",
        havingValue = "stripe"
)
public PaymentService stripePaymentService() {
    return new StripePaymentService();
}

Agar configda shunday bo‘lsa:

payment:
  provider: stripe

Spring StripePaymentService beanini yaratadi.

Agar:

payment:
  provider: click

bo‘lsa, bu bean yaratilmaydi.

12. Spring Boot auto-configuration nima?

Spring Bootning eng kuchli joyi - auto-configuration.

Biz dependency qo‘shamiz:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>

Spring Boot shuni ko‘radi va o‘zi taxmin qiladi:

"Demak bu project JPA ishlatyapti. Men EntityManager, DataSource, TransactionManager kerak bo‘lishini bilaman."

Keyin kerakli beanlarni avtomatik yaratadi.

Lekin bu sehr emas. Ichkarida shartlar bor:

@ConditionalOnClass(DataSource.class)
@ConditionalOnMissingBean(DataSource.class)

Ma’nosi:

Agar classpathda DataSource bo‘lsa
va user o‘zi DataSource bean yaratmagan bo‘lsa,
Spring Boot default DataSource yaratadi.

13. @ConditionalOnMissingBean juda muhim

Bu Spring Boot auto-configurationning asosiy g‘oyasi.

Masalan Spring Boot default ObjectMapper yaratadi.

Lekin biz o‘zinmiz bersak:

@Bean
public ObjectMapper objectMapper() {
    return new ObjectMapper()
            .findAndRegisterModules();
}

Spring Boot aytadi:

"User o‘zi ObjectMapper berdi. Men defaultini yaratmayman."

Shu sabab Spring Boot moslashuvchan.

14. Auto-configuration eski va yangi mexanizmi

Oldin Spring Boot auto-config classlar odatda bu faylda ko‘rsatilardi:

META-INF/spring.factories

Yangi Spring Boot versiyalarida esa:

META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports

O'rta darajada buni bilish muhim, chunki custom starter yozganda kerak bo‘ladi.

15. @Import nima?

@Import - boshqa configuration classni Spring contextga qo‘shish.

Misol:

@Configuration
public class SecurityConfig {
}

Buni boshqa joyda import qilish:

@Configuration
@Import(SecurityConfig.class)
public class AppConfig {
}

Endi SecurityConfig ichidagi beanlar ham contextga qo‘shiladi.

@Import ko‘pincha:

• custom configuration ulashda;

• starter yozishda;

• framework ichki mexanizmlarida;

• modular configlarda ishlatiladi.

16. Bean scope nima?

Scope - bean qancha vaqt yashashini belgilaydi.

Eng ko‘p ishlatiladiganlari:

Default scope - singleton.

17. Singleton scope

@Service
public class UserService {
}

Bu default holatda singleton.

Ya’ni Spring bitta UserService obyekt yaratadi va hamma joyda shuni ishlatadi.

Controller A ─┐
Controller B ─┼──> same UserService object
Controller C ─┘

Shuning uchun singleton beanda mutable state saqlash xavfli.

Yomon:

@Service
public class OrderService {

    private Long currentUserId;

    public void createOrder(Long userId) {
        this.currentUserId = userId;
    }
}

Bu productionda bug beradi, chunki bir vaqtning o‘zida ko‘p request keladi.

Yaxshi:

@Service
public class OrderService {

    public void createOrder(Long userId) {
        // userId local variable sifatida ishlatiladi
    }
}

18. Prototype scope

@Component
@Scope("prototype")
public class ReportBuilder {
}

Har safar so‘ralganda yangi obyekt yaratiladi.

ReportBuilder builder1 = context.getBean(ReportBuilder.class);
ReportBuilder builder2 = context.getBean(ReportBuilder.class);

Bu yerda:

builder1 != builder2

Lekin muhim joy bor.

Agar prototype bean singleton ichiga inject qilinsa:

@Service
public class ReportService {

    private final ReportBuilder reportBuilder;

    public ReportService(ReportBuilder reportBuilder) {
        this.reportBuilder = reportBuilder;
    }
}

ReportService singleton bo‘lgani uchun ReportBuilder ham faqat bir marta inject bo‘ladi.

Har safar yangi prototype olish uchun ObjectProvider ishlatiladi:

@Service
public class ReportService {

    private final ObjectProvider<ReportBuilder> builderProvider;

    public ReportService(ObjectProvider<ReportBuilder> builderProvider) {
        this.builderProvider = builderProvider;
    }

    public void generate() {
        ReportBuilder builder = builderProvider.getObject();
    }
}

19. Request scope

Har HTTP request uchun alohida bean.

@Component
@RequestScope
public class RequestContext {

    private String requestId;

    public String getRequestId() {
        return requestId;
    }

    public void setRequestId(String requestId) {
        this.requestId = requestId;
    }
}

Bu web applicationlarda foydali:

• request id;

• user context;

• tenant id;

• request-specific data.

Lekin ehtiyot bo‘lish kerak. Hamma narsani request scope qilish noto‘g‘ri. Ko‘pincha ThreadLocal, filter, interceptor yoki security context yaxshiroq bo‘ladi.

20. Spring application start bo‘lish jarayoni

Soddalashtirilgan ketma-ketlik:

SpringApplication.run(App.class, args);

Ichkarida taxminan:

1. SpringApplication yaratiladi
2. Environment tayyorlanadi
3. ApplicationContext yaratiladi
4. BeanDefinitionlar yuklanadi
5. BeanFactoryPostProcessorlar ishlaydi
6. Singleton beanlar yaratiladi
7. BeanPostProcessorlar ishlaydi
8. Embedded server start bo‘ladi
9. ApplicationReadyEvent chiqadi

Shuning uchun @PostConstruct paytida application hali to‘liq tayyor bo‘lmasligi mumkin.

Agar app to‘liq ishga tushgandan keyin nimadir qilish kerak bo‘lsa, ko‘pincha bu yaxshiroq:

@Component
public class StartupRunner implements ApplicationRunner {

    @Override
    public void run(ApplicationArguments args) {
        System.out.println("Application started");
    }
}

Yoki:

@Component
public class ReadyListener {

    @EventListener(ApplicationReadyEvent.class)
    public void onReady() {
        System.out.println("Application is fully ready");
    }
}

21. Spring Internals real hayotda nimaga kerak?

1. @Transactional nega ishlamayotganini tushunish uchun

Masalan:

@Service
public class UserService {

    public void create() {
        saveUser();
    }

    @Transactional
    public void saveUser() {
        // DB save
    }
}

Bu yerda @Transactional ishlamasligi mumkin.

Sabab: self-invocation.

create() ichidan saveUser() chaqirilganda proxy chetlab o‘tiladi.

To‘g‘ri yechimlardan biri:

@Service
public class UserFacade {

    private final UserService userService;

    public UserFacade(UserService userService) {
        this.userService = userService;
    }

    public void create() {
        userService.saveUser();
    }
}

@Service
public class UserService {

    @Transactional
    public void saveUser() {
        // DB save
    }
}

2. Bean circular dependency muammosini tushunish uchun

Yomon:

@Service
public class AService {
    public AService(BService bService) {}
}

@Service
public class BService {
    public BService(AService aService) {}
}

Bu circular dependency.

AService BServicega muhtoj
BService AServicega muhtoj

Yaxshi yechim - responsibilityni ajratish:

@Service
public class CommonService {
}

Yoki arxitekturani qayta ko‘rib chiqish.

3. Startup sekinligini topish uchun

Agar app sekin start bo‘lsa, sabablar:

• juda ko‘p eager singleton bean;

• @PostConstruct ichida og‘ir ish;

• DB/API calllar startupda bajarilishi;

• noto‘g‘ri auto-configuration;

• classpathda keraksiz starterlar.

22. Java developer bilishi kerak bo‘lgan xulosa

Java Spring developer faqat annotation ishlatmaydi. U annotation ortida nima bo‘layotganini tushunadi.

23. Interview savollar

Savol 1: Bean lifecycle qanday?

Javob:

Spring avval classlarni scan qiladi, BeanDefinition yaratadi, keyin bean obyektini yaratadi, dependency injection qiladi, BeanPostProcessorlarni ishlatadi, init methodlarni chaqiradi va bean tayyor bo‘ladi. Application yopilganda destroy callbacklar ishlaydi.

Savol 2: BeanPostProcessor va BeanFactoryPostProcessor farqi nima?

Javob:

BeanFactoryPostProcessor bean yaratilishidan oldin BeanDefinition bilan ishlaydi. BeanPostProcessor esa bean yaratilgandan keyin real obyekt bilan ishlaydi.

Savol 3: @Transactional nega ba’zida ishlamaydi?

Javob:

Chunki Spring @Transactionalni proxy orqali ishlatadi. Agar method shu class ichidan o‘zini o‘zi chaqirsa, proxy chetlab o‘tiladi va transaction ochilmaydi.

Savol 4: Singleton beanda fieldda request data saqlash mumkinmi?

Javob:

Yo‘q. Singleton bean barcha requestlar uchun bitta obyekt bo‘ladi. Mutable fieldlar race condition va noto‘g‘ri data muammosiga olib keladi.

Savol 5: Auto-configuration qanday ishlaydi?

Javob:

Spring Boot classpath, property va mavjud beanlarga qarab shartli configurationlarni ishga tushiradi. Masalan @ConditionalOnClass, @ConditionalOnMissingBean, @ConditionalOnProperty orqali kerakli default beanlarni yaratadi.

24. Amaliy mini-topshiriq

Quyidagi kichik projectda sinab ko‘ring:

@Component
public class DemoBean {

    public DemoBean() {
        System.out.println("Constructor");
    }

    @PostConstruct
    public void init() {
        System.out.println("PostConstruct");
    }

    @PreDestroy
    public void destroy() {
        System.out.println("PreDestroy");
    }
}

Keyin BeanPostProcessor qo‘shing:

@Component
public class LoggingBeanPostProcessor implements BeanPostProcessor {

    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) {
        if (beanName.equals("demoBean")) {
            System.out.println("Before init: " + beanName);
        }
        return bean;
    }

    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) {
        if (beanName.equals("demoBean")) {
            System.out.println("After init: " + beanName);
        }
        return bean;
    }
}

Taxminiy natija:

Constructor
Before init: demoBean
PostConstruct
After init: demoBean

Bu Spring lifecycle’ni ko‘z bilan ko‘rishga yordam beradi.

Bu maqola quyidagilarni qamrab oladi: custom auto-configuration, custom starter, custom Actuator endpoint, custom annotation + AOP, ApplicationListener, SmartLifecycle.

1. Custom Spring extensions nima?

Oddiy developer Spring Boot’dan tayyor holda foydalanadi:

spring-boot-starter-web
spring-boot-starter-data-jpa
spring-boot-starter-security

Senior developer esa kerak bo‘lsa o‘zi ham shunday reusable extension yozadi:

company-security-starter
company-observability-starter
company-multitenancy-starter
company-kafka-starter
company-audit-starter

Maqsad:

Bir xil config va boilerplate kodni har projectda qayta yozmaslik.

Masalan, kompaniyada 20 ta microservice bor. Har birida quyidagilar kerak:

JWT security config
Tracing config
Audit logging
Tenant filter
Kafka error handler
Actuator custom endpoint
Common exception handler

Bularni har service’da copy-paste qilish yomon. Yaxshiroq yechim:

company-platform-starter

2. Qachon custom extension kerak?

Custom extension kerak bo‘ladi:

[+] Bir xil config 3+ projectda takrorlansa
[+] Platform team umumiy standart bermoqchi bo‘lsa
[+] Security/observability/kafka config markazlashtirilsa
[+] Internal library reusable bo‘lishi kerak bo‘lsa
[+] Teamlar bir xil convention bilan ishlashi kerak bo‘lsa

Kerak emas:

[-] Faqat bitta project uchun bo‘lsa
[-] Oddiy 2-3 ta bean uchun ortiqcha abstraction bo‘lsa
[-] Extension projectni tushunishni qiyinlashtirsa
[-] Team hali Spring internals’ni yaxshi bilmasa

Senior qoida:

Abstraction foyda bersa yoziladi. Faqat "chiroyli ko‘rinsin" deb starter yozilmaydi.

3. Custom auto-configuration

Auto-configuration nima?

Spring Boot auto-configuration classpath’dagi dependency va mavjud beanlarga qarab avtomatik config qiladi. Rasmiy hujjatda Spring Boot auto-configuration application’ni qo‘shilgan jar dependency’lar asosida avtomatik sozlashga urinishi aytiladi. (Home)

Masalan:

spring-boot-starter-data-jpa bor
↓
DataSource kerak
↓
Hibernate kerak
↓
JpaRepository kerak
↓
Spring Boot ko‘p config’ni o‘zi qiladi

Custom auto-configuration ham xuddi shunday:

company-audit-starter dependency qo‘shildi
↓
AuditLogger bean avtomatik yaratildi
↓
AuditAspect avtomatik yoqildi

Oddiy custom auto-configuration misol

Tasavvur qilamiz, bizda audit logging library bor.

1. Properties class

package uz.company.audit;

import org.springframework.boot.context.properties.ConfigurationProperties;

@ConfigurationProperties(prefix = "company.audit")
public class AuditProperties {

    private boolean enabled = true;
    private String applicationName = "unknown-service";

    public boolean isEnabled() {
        return enabled;
    }

    public void setEnabled(boolean enabled) {
        this.enabled = enabled;
    }

    public String getApplicationName() {
        return applicationName;
    }

    public void setApplicationName(String applicationName) {
        this.applicationName = applicationName;
    }
}

2. Audit service

package uz.company.audit;

public class AuditLogger {

    private final AuditProperties properties;

    public AuditLogger(AuditProperties properties) {
        this.properties = properties;
    }

    public void log(String action, String userId) {
        System.out.printf(
                "audit app=%s action=%s userId=%s%n",
                properties.getApplicationName(),
                action,
                userId
        );
    }
}

3. Auto-configuration class

package uz.company.audit.autoconfigure;

import uz.company.audit.AuditLogger;
import uz.company.audit.AuditProperties;
import org.springframework.boot.autoconfigure.AutoConfiguration;
import org.springframework.boot.autoconfigure.condition.ConditionalOnMissingBean;
import org.springframework.boot.autoconfigure.condition.ConditionalOnProperty;
import org.springframework.boot.context.properties.EnableConfigurationProperties;
import org.springframework.context.annotation.Bean;

@AutoConfiguration
@EnableConfigurationProperties(AuditProperties.class)
@ConditionalOnProperty(
        prefix = "company.audit",
        name = "enabled",
        havingValue = "true",
        matchIfMissing = true
)
public class AuditAutoConfiguration {

    @Bean
    @ConditionalOnMissingBean
    public AuditLogger auditLogger(AuditProperties properties) {
        return new AuditLogger(properties);
    }
}

Spring Boot custom auto-configuration yaratish bo‘yicha rasmiy hujjatda auto-configuration starter bilan bog‘lanishi, starter esa auto-configuration code va kerakli library’larni olib kelishi tushuntiriladi. (Home)

4. AutoConfiguration.imports

Spring Boot 3'da auto-configuration class’ni e’lon qilish uchun odatda quyidagi file ishlatiladi:

src/main/resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports

Ichida:

uz.company.audit.autoconfigure.AuditAutoConfiguration

Shundan keyin boshqa project dependency qo‘shsa, Spring Boot bu auto-configuration’ni ko‘radi.

5. Conditional annotations

Custom extension yozishda eng muhim narsa - shartli ishlash.

Yomon starter:

Dependency qo‘shilishi bilan hamma narsani majburan yaratadi.

Yaxshi starter:

Faqat kerakli class/property/bean bo‘lsa ishlaydi.
User o‘z bean’ini bersa, starter chekinadi.

Muhim condition annotationlar

Misol:

@Bean
@ConditionalOnMissingBean
public AuditLogger auditLogger(AuditProperties properties) {
    return new AuditLogger(properties);
}

Bu nima degani?

Agar user o‘zi AuditLogger bean bermagan bo‘lsa,
starter default AuditLogger yaratadi.

Bu extension yozishda juda muhim odob:

User override qila olishi kerak.

6. Custom starter

Starter nima?

Starter - dependencylarni va auto-configuration’ni bir joyga yig‘adigan library.

Masalan:

<dependency>
    <groupId>uz.company</groupId>
    <artifactId>company-audit-spring-boot-starter</artifactId>
    <version>1.0.0</version>
</dependency>

Shuni qo‘shgan project avtomatik quyidagilarga ega bo‘ladi:

AuditProperties
AuditLogger
AuditAspect
Audit actuator endpoint
Audit metrics

Starter project structure

company-audit-spring-boot-starter/
  src/main/java/
    uz/company/audit/
      AuditLogger.java
      AuditProperties.java
      AuditAspect.java

    uz/company/audit/autoconfigure/
      AuditAutoConfiguration.java

  src/main/resources/
    META-INF/spring/
      org.springframework.boot.autoconfigure.AutoConfiguration.imports

  pom.xml

Starter pom.xml

<project>
    <groupId>uz.company</groupId>
    <artifactId>company-audit-spring-boot-starter</artifactId>
    <version>1.0.0</version>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-autoconfigure</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-configuration-processor</artifactId>
            <optional>true</optional>
        </dependency>

        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-aop</artifactId>
        </dependency>
    </dependencies>
</project>

spring-boot-configuration-processor foydasi:

application.yml da autocomplete va metadata beradi.

Masalan:

company:
  audit:
    enabled: true
    application-name: order-service

7. Starter ishlatish

Boshqa microservice’da faqat dependency qo‘shiladi:

<dependency>
    <groupId>uz.company</groupId>
    <artifactId>company-audit-spring-boot-starter</artifactId>
    <version>1.0.0</version>
</dependency>

Config:

company:
  audit:
    enabled: true
    application-name: order-service

Service’da:

@Service
@RequiredArgsConstructor
public class OrderService {

    private final AuditLogger auditLogger;

    public void cancelOrder(Long orderId, String userId) {
        auditLogger.log("ORDER_CANCELLED", userId);
    }
}

Bitta starter bilan 20 ta service’da bir xil audit standard ishlaydi.

8. Custom annotation + AOP

Muammo

Audit logni har joyda qo‘lda chaqirish ham boilerplate:

auditLogger.log("ORDER_CANCELLED", userId);

Yaxshiroq:

@Auditable(action = "ORDER_CANCELLED")
public void cancelOrder(Long orderId) {
    ...
}

Custom annotation

package uz.company.audit;

import java.lang.annotation.*;

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Auditable {
    String action();
}

Aspect

package uz.company.audit;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;

@Aspect
public class AuditAspect {

    private final AuditLogger auditLogger;
    private final CurrentUserProvider currentUserProvider;

    public AuditAspect(
            AuditLogger auditLogger,
            CurrentUserProvider currentUserProvider
    ) {
        this.auditLogger = auditLogger;
        this.currentUserProvider = currentUserProvider;
    }

    @Around("@annotation(auditable)")
    public Object audit(
            ProceedingJoinPoint joinPoint,
            Auditable auditable
    ) throws Throwable {
        String userId = currentUserProvider.getCurrentUserId();

        try {
            Object result = joinPoint.proceed();

            auditLogger.log(auditable.action() + "_SUCCESS", userId);

            return result;
        } catch (Throwable ex) {
            auditLogger.log(auditable.action() + "_FAILED", userId);
            throw ex;
        }
    }
}

Auto-config’da aspect qo‘shamiz:

@Bean
@ConditionalOnMissingBean
public AuditAspect auditAspect(
        AuditLogger auditLogger,
        CurrentUserProvider currentUserProvider
) {
    return new AuditAspect(auditLogger, currentUserProvider);
}

Ishlatish

@Service
public class OrderService {

    @Auditable(action = "ORDER_CANCELLED")
    public void cancelOrder(Long orderId) {
        // business logic
    }
}

Natija:

Method success bo‘lsa → ORDER_CANCELLED_SUCCESS
Exception bo‘lsa → ORDER_CANCELLED_FAILED

9. Custom annotation yozishda ehtiyot bo‘lish

1. Self-invocation muammosi

Spring AOP proxy orqali ishlaydi.

@Service
public class OrderService {

    public void methodA() {
        methodB(); // self call
    }

    @Auditable(action = "METHOD_B")
    public void methodB() {
    }
}

Bu holatda methodB() annotation’i ishlamasligi mumkin, chunki chaqiriq proxy’dan o‘tmaydi.

Yechimlar:

- Annotated methodni boshqa bean’ga chiqarish
- AspectJ weaving ishlatish
- Self-invocation’dan qochish

2. Private methodlarga AOP ishlamasligi

Yomon:

@Auditable(action = "PRIVATE")
private void doWork() {
}

Spring AOP odatda public/proxy orqali chaqiriladigan methodlarda ishlaydi.

3. Annotation business logic’ni yashirib yubormasin

Annotation juda ko‘payib ketsa:

@Auditable
@Retryable
@Transactional
@Cacheable
@PreAuthorize

methodning real behavior’ini tushunish qiyinlashadi.

Senior qoida:

Annotation abstraction bo‘lsa ham, behavior aniq va predictable bo‘lsin.

10. Custom Actuator endpoint

Nima uchun kerak?

Spring Boot Actuator application’ni kuzatish va boshqarish uchun endpointlar beradi; rasmiy hujjatda Actuator ichki endpointlardan tashqari custom endpoint qo‘shish imkonini ham berishi aytiladi. (Home)

Custom endpoint misollar:

/actuator/features
/actuator/tenants
/actuator/build-info
/actuator/kafka-status
/actuator/outbox

Custom endpoint misol

package uz.company.platform.actuator;

import org.springframework.boot.actuate.endpoint.annotation.Endpoint;
import org.springframework.boot.actuate.endpoint.annotation.ReadOperation;

import java.util.Map;

@Endpoint(id = "features")
public class FeatureFlagsEndpoint {

    private final FeatureFlagService featureFlagService;

    public FeatureFlagsEndpoint(FeatureFlagService featureFlagService) {
        this.featureFlagService = featureFlagService;
    }

    @ReadOperation
    public Map<String, Boolean> features() {
        return featureFlagService.getAllFlags();
    }
}

Auto-config:

@Bean
@ConditionalOnBean(FeatureFlagService.class)
public FeatureFlagsEndpoint featureFlagsEndpoint(
        FeatureFlagService featureFlagService
) {
    return new FeatureFlagsEndpoint(featureFlagService);
}

Config:

management:
  endpoints:
    web:
      exposure:
        include: health,info,features

Endpoint:

GET /actuator/features

Response:

{
  "paymentV2": true,
  "newCheckout": false
}

Custom Actuator endpoint xavfsizligi

Actuator endpointlar production’da ehtiyotkorlik bilan ochiladi.

Yomon:

management:
  endpoints:
    web:
      exposure:
        include: "*"

Yaxshi:

management:
  endpoints:
    web:
      exposure:
        include: health,info,prometheus,features

Security config:

@Bean
SecurityFilterChain actuatorSecurity(HttpSecurity http) throws Exception {
    return http
            .securityMatcher("/actuator/**")
            .authorizeHttpRequests(auth -> auth
                    .requestMatchers("/actuator/health").permitAll()
                    .requestMatchers("/actuator/prometheus").hasRole("MONITORING")
                    .anyRequest().hasRole("ADMIN")
            )
            .build();
}

Senior qoida:

Actuator endpoint operational data beradi. Uni public ochmang.

11. Custom HealthIndicator

Agar sizda muhim dependency bo‘lsa, custom health indicator yozish mumkin.

Masalan, payment provider status:

@Component
public class PaymentProviderHealthIndicator implements HealthIndicator {

    private final PaymentProviderClient client;

    public PaymentProviderHealthIndicator(PaymentProviderClient client) {
        this.client = client;
    }

    @Override
    public Health health() {
        try {
            boolean ok = client.ping();

            if (ok) {
                return Health.up()
                        .withDetail("provider", "payment-provider")
                        .build();
            }

            return Health.down()
                    .withDetail("provider", "payment-provider")
                    .build();
        } catch (Exception ex) {
            return Health.down(ex).build();
        }
    }
}

Lekin ehtiyot:

Har dependency’ni liveness ichiga qo‘shmang.
Critical dependency readiness’da bo‘lishi mumkin.

12. Application events

Spring ichida event publish/listen qilish mumkin.

Event class

public record OrderCreatedEvent(
        Long orderId,
        Long userId
) {}

Publish qilish

@Service
@RequiredArgsConstructor
public class OrderService {

    private final ApplicationEventPublisher eventPublisher;

    @Transactional
    public void createOrder(CreateOrderRequest request) {
        Order order = saveOrder(request);

        eventPublisher.publishEvent(
                new OrderCreatedEvent(order.getId(), order.getUserId())
        );
    }
}

Listen qilish

@Component
public class OrderCreatedListener {

    @EventListener
    public void handle(OrderCreatedEvent event) {
        System.out.println("Order created: " + event.orderId());
    }
}

13. Transactional event listener

Oddiy @EventListener transaction ichida darhol ishlashi mumkin.

Agar eventni faqat DB commit bo‘lgandan keyin ishlatmoqchi bo‘lsangiz:

@Component
public class OrderCreatedListener {

    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    public void handle(OrderCreatedEvent event) {
        // DB commit bo‘lgandan keyin ishlaydi
    }
}

Bu muhim.

Yomon flow:

Order save qilindi
Event publish qilindi
Listener notification yubordi
Keyin DB transaction rollback bo‘ldi

Natija:

User notification oldi, lekin order DB’da yo‘q.

Yaxshi:

DB commit
↓
AFTER_COMMIT listener
↓
Notification

14. @Async event listener

Event listener’ni async qilish mumkin:

@Component
public class OrderCreatedListener {

    @Async("eventExecutor")
    @EventListener
    public void handle(OrderCreatedEvent event) {
        // background processing
    }
}

Executor:

@Configuration
@EnableAsync
public class AsyncConfig {

    @Bean
    public Executor eventExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(5);
        executor.setMaxPoolSize(20);
        executor.setQueueCapacity(1000);
        executor.setThreadNamePrefix("event-");
        executor.initialize();
        return executor;
    }
}

Ehtiyot:

Async event transaction boundary va error handlingni murakkablashtiradi.

Agar event juda muhim bo‘lsa:

Spring event emas, outbox + Kafka ishlating.

15. ApplicationListener

@EventListener o‘rniga class-based listener ham yozish mumkin.

@Component
public class OrderCreatedApplicationListener
        implements ApplicationListener<OrderCreatedEvent> {

    @Override
    public void onApplicationEvent(OrderCreatedEvent event) {
        System.out.println("Order created: " + event.orderId());
    }
}

Qachon kerak?

- Framework-level extension yozilganda
- Generic listener kerak bo‘lsa
- Starter ichida explicit contract kerak bo‘lsa

16. Spring Boot lifecycle events

Spring Boot application start paytida turli eventlar chiqaradi.

Ko‘p ishlatiladiganlari:

Masalan:

@Component
public class StartupLogger {

    @EventListener(ApplicationReadyEvent.class)
    public void onReady() {
        System.out.println("Application is ready");
    }
}

ApplicationReadyEvent - warmup yoki startup tugaganidan keyingi ishlar uchun qulay.

Lekin og‘ir ishni shu yerda sync bajarish ham app readiness’ga ta’sir qilishi mumkin.

17. SmartLifecycle

Nima?

SmartLifecycle - Spring context start/stop jarayonida komponentni boshqarish uchun ishlatiladi.

Masalan:

Kafka consumerni custom start qilish
Background worker boshlash
Scheduler-like processor ishga tushirish
External connection ochish
Graceful shutdown’da to‘xtatish

Spring Framework SmartLifecycle interface’i Lifecycle'ni kengaytiradi va auto-startup, phase kabi imkoniyatlar beradi. (Home)

SmartLifecycle misol

@Component
public class OutboxWorkerLifecycle implements SmartLifecycle {

    private final OutboxWorker worker;
    private volatile boolean running = false;

    public OutboxWorkerLifecycle(OutboxWorker worker) {
        this.worker = worker;
    }

    @Override
    public void start() {
        worker.start();
        running = true;
    }

    @Override
    public void stop() {
        worker.stop();
        running = false;
    }

    @Override
    public boolean isRunning() {
        return running;
    }

    @Override
    public boolean isAutoStartup() {
        return true;
    }

    @Override
    public int getPhase() {
        return 100;
    }
}

getPhase() nima?

Phase start/stop tartibini boshqaradi.

Kichik phase → oldin start
Katta phase → keyin start

Stop paytida aksincha:
Katta phase → oldin stop
Kichik phase → keyin stop

Masalan:

Database connection manager phase=0
Outbox worker phase=100

Start:

DB avval
Worker keyin

Stop:

Worker avval
DB keyin

Bu graceful shutdown uchun juda foydali.

18. Custom BeanPostProcessor

Nima?

BeanPostProcessor bean yaratilgandan keyin uni o‘zgartirish yoki tekshirish imkonini beradi.

Bu advanced Spring internals mavzusi.

Misol: @Sensitive annotationli beanlarni startup’da tekshirish.

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface SensitiveComponent {
}

Processor:

@Component
public class SensitiveBeanPostProcessor implements BeanPostProcessor {

    @Override
    public Object postProcessAfterInitialization(
            Object bean,
            String beanName
    ) throws BeansException {

        if (bean.getClass().isAnnotationPresent(SensitiveComponent.class)) {
            System.out.println("Sensitive bean registered: " + beanName);
        }

        return bean;
    }
}

Ehtiyot:

BeanPostProcessor noto‘g‘ri yozilsa, butun application context behavior’i buzilishi mumkin.

Buni faqat haqiqiy zaruratda ishlating.

19. Custom annotation for validation

Spring extension faqat AOP emas. Bean Validation uchun ham custom annotation yoziladi.

Annotation

@Target({ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = PhoneNumberValidator.class)
public @interface ValidUzPhone {

    String message() default "Invalid Uzbekistan phone number";

    Class<?>[] groups() default {};

    Class<? extends Payload>[] payload() default {};
}

Validator

public class PhoneNumberValidator
        implements ConstraintValidator<ValidUzPhone, String> {

    private static final Pattern PATTERN =
            Pattern.compile("^\\+998\\d{9}$");

    @Override
    public boolean isValid(String value, ConstraintValidatorContext context) {
        if (value == null || value.isBlank()) {
            return true;
        }

        return PATTERN.matcher(value).matches();
    }
}

Ishlatish

public record RegisterRequest(
        @NotBlank String name,
        @ValidUzPhone String phone
) {}

20. Custom meta-annotation

Ba’zida bir nechta annotationni bitta annotationga yig‘ish mumkin.

Masalan:

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@PreAuthorize("hasAuthority('SCOPE_orders.write')")
@Transactional
@Auditable(action = "ORDER_WRITE")
public @interface OrderWriteOperation {
}

Ishlatish:

@OrderWriteOperation
public void cancelOrder(Long orderId) {
    ...
}

Ehtiyot:

Meta-annotation behaviorni yashirib yuborishi mumkin.
Team buni yaxshi tushunsa ishlating.

21. Custom starter uchun test

Starter yozsangiz, uni albatta test qilish kerak.

Spring Boot’da ApplicationContextRunner custom auto-configuration testlari uchun juda qulay.

class AuditAutoConfigurationTest {

    private final ApplicationContextRunner contextRunner =
            new ApplicationContextRunner()
                    .withConfiguration(
                            AutoConfigurations.of(AuditAutoConfiguration.class)
                    );

    @Test
    void shouldCreateAuditLoggerByDefault() {
        contextRunner.run(context -> {
            assertThat(context).hasSingleBean(AuditLogger.class);
        });
    }

    @Test
    void shouldDisableAuditWhenPropertyFalse() {
        contextRunner
                .withPropertyValues("company.audit.enabled=false")
                .run(context -> {
                    assertThat(context).doesNotHaveBean(AuditLogger.class);
                });
    }

    @Test
    void shouldBackOffWhenUserProvidesAuditLogger() {
        contextRunner
                .withBean(AuditLogger.class, () -> new CustomAuditLogger())
                .run(context -> {
                    assertThat(context).hasSingleBean(AuditLogger.class);
                });
    }
}

Test qilinadigan narsalar:

[ ] Default bean yaratiladimi?
[ ] Property orqali o‘chadimi?
[ ] User custom bean bersa back off qiladimi?
[ ] Kerakli class yo‘q bo‘lsa ishlamayaptimi?
[ ] Web/non-web context farqi to‘g‘rimi?

22. Versioning va compatibility

Internal starter ham product kabi versionlanadi.

Yomon:

company-starter:latest

Yaxshi:

company-starter:1.4.2

Semantic versioning:

Senior qoida:

Starter yangilanishi 20 ta service’ni buzmasligi kerak.

23. Real example: company observability starter

Kompaniyada har microservice’da bir xil observability kerak:

traceId loglarda
common MDC filter
custom metrics
standard actuator exposure
correlation id
exception metrics

Starter:

company-observability-starter

Ichida:

CorrelationIdFilter
MdcLoggingFilter
CommonTagsCustomizer
CustomHealthIndicator
Actuator endpoint
AutoConfiguration
Properties

Service’da faqat:

<dependency>
    <groupId>uz.company</groupId>
    <artifactId>company-observability-starter</artifactId>
    <version>1.0.0</version>
</dependency>

Config:

company:
  observability:
    correlation-id-header: X-Correlation-Id
    service-name: order-service

Natija:

Hamma service bir xil log format
Hamma service bir xil metrics tag
Hamma service bir xil correlation id handling

Bu custom Spring extension’ning haqiqiy foydasi.

24. Common mistakes

1. Starter juda ko‘p ish qiladi

Yomon:

company-platform-starter
  security
  kafka
  database
  redis
  actuator
  tracing
  exception
  migration
  cache

Bunday starter juda og‘ir bo‘ladi.

Yaxshiroq:

company-security-starter
company-kafka-starter
company-observability-starter
company-multitenancy-starter

2. Override qilish imkoni yo‘q

Yomon:

@Bean
public AuditLogger auditLogger() {
    return new AuditLogger();
}

Yaxshi:

@Bean
@ConditionalOnMissingBean
public AuditLogger auditLogger() {
    return new AuditLogger();
}

3. Property bilan o‘chirib bo‘lmaydi

Har starterda disable option bo‘lsin:

company:
  audit:
    enabled: false

4. Internal API documentation yo‘q

Starterda README bo‘lishi kerak:

- Nima qiladi?
- Qanday dependency qo‘shiladi?
- Qanday config bor?
- Default behavior nima?
- Qanday override qilinadi?
- Qanday troubleshoot qilinadi?

5. Auto-config haddan tashqari agressiv

Starter user project’da kutilmagan bean yaratmasligi kerak.

25. Custom Spring extensions checklist

[ ] Extension haqiqatan reusablemi?
[ ] Auto-configuration shartli ishlaydimi?
[ ] @ConditionalOnMissingBean ishlatilganmi?
[ ] Property orqali enable/disable bormi?
[ ] ConfigurationProperties bor-mi?
[ ] Metadata/autocomplete uchun configuration processor bormi?
[ ] AutoConfiguration.imports to‘g‘ri yozilganmi?
[ ] Actuator endpointlar secure qilinganmi?
[ ] AOP self-invocation muammosi hisobga olinganmi?
[ ] Lifecycle start/stop tartibi aniqmi?
[ ] ApplicationContextRunner bilan test qilinganmi?
[ ] Versioning strategy bormi?
[ ] README va config example bormi?
[ ] Breaking change release’da aniq yozilganmi?

26. Senior interview javob

Suhbatda so‘rasa:

Custom Spring starter yoki auto-configuration yozganmisiz? Qanday ishlaydi?

Javob:

Custom Spring starter umumiy platform config’ni reusable qilish uchun yoziladi.
Masalan, company-observability-starter yoki company-security-starter.

Starter ichida auto-configuration class bo‘ladi, u @AutoConfiguration bilan belgilanadi va
META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports file orqali Spring Boot’ga tanitiladi.

Auto-configuration majburan bean yaratmasligi kerak. Shuning uchun @ConditionalOnClass,
@ConditionalOnProperty, @ConditionalOnMissingBean kabi condition annotationlar ishlatiladi.
User o‘z bean’ini bersa, starter back off qilishi kerak.

ConfigurationProperties orqali application.yml’dan type-safe config olinadi.
Agar kerak bo‘lsa custom annotation + AOP, custom Actuator endpoint, HealthIndicator,
ApplicationListener yoki SmartLifecycle qo‘shiladi.

Bunday starter ApplicationContextRunner bilan test qilinadi:
default bean yaratilishi, property bilan disable bo‘lishi, user custom bean bersa override ishlashi tekshiriladi.

27. Qisqa xulosa

Custom Spring extensions Senior developer uchun Spring ekotizimini chuqur tushunishni ko‘rsatadi.

Qisqa xulosa qilsak:

Custom extension - takrorlanadigan platform kodni reusable, configurable va override qilinadigan Spring module’ga aylantirish.

Eng muhim tushunchalar:

Bu bo‘lim ichida quyidagilar bor: RestTemplate, WebClient, HttpInterface, timeout va retry configuration.

1. REST client nima?

Oldingi darslarda biz REST API yozdik:

Frontend / Mobile App → Spring Boot API → Database

Lekin real loyihada backend faqat database bilan ishlamaydi. U boshqa servislar bilan ham gaplashadi:

Spring Boot API → Payment service
Spring Boot API → SMS service
Spring Boot API → Telegram bot API
Spring Boot API → CRM service
Spring Boot API → Currency exchange API
Spring Boot API → Delivery service

Mana shu tashqi servisga HTTP request yuboradigan qism REST client deyiladi.

2. Server va client farqi

Biz server bo‘lgan holat

Frontend bizga request yuboradi:

GET /api/products

Bizning controller javob qaytaradi:

@GetMapping("/api/products")
public List<ProductResponse> getProducts() {
    return productService.getProducts();
}

Bu yerda biz servermiz.

Biz client bo‘lgan holat

Biz boshqa servisga request yuboramiz:

GET https://api.example.com/currency/USD

Bu yerda biz clientmiz.

Bizning Spring Boot app → tashqi API

3. HTTP qisqa eslatma

REST client ishlatishdan oldin HTTP asoslarini bilish kerak.

HTTP methodlar

HTTP status code

REST client yozganda status codelarni to‘g‘ri ushlash juda muhim.

4. Spring’da REST client variantlari

Spring’da bir nechta HTTP client bor:

RestTemplate
RestClient
WebClient
HttpInterface

Spring Framework 6.1+ da RestClient ham bor, shuni ham bilib qo‘yish foydali.

Spring rasmiy hujjatlarida RestTemplate synchronous HTTP client ekani aytilgan. WebClient esa non-blocking reactive client sifatida ta’riflanadi. (Home)

5. Blocking va non-blocking farqi

Blocking

Request yuboriladi va thread javob kelguncha kutadi.

Thread → request yubordi → javob kutdi → davom etdi

RestTemplate va RestClient blocking client hisoblanadi.

Oddiy backend API’lar uchun tushunish oson.

Non-blocking

Request yuboriladi, lekin thread bekor kutib turmaydi.

Thread → request yubordi → boshqa ishga o‘tdi
Javob kelganda callback/reactive pipeline ishlaydi

WebClient non-blocking reactive client. Rasmiy hujjatlarda WebClient request bajarish uchun HTTP client library kerak qilishi va Reactor Netty, JDK HttpClient, Jetty Reactive HttpClient kabi variantlarni qo‘llashi aytiladi. (Home)

6. Qaysi birini tanlash kerak?

Java developer uchun amaliy qoida:

Legacy project → RestTemplate ko‘rasiz
Oddiy modern blocking API → RestClient
Reactive/WebFlux project → WebClient
Boilerplate kamaytirish → HttpInterface

Agar siz hozir Spring Boot MVC bilan oddiy REST API yozayotgan bo‘lsangiz:

RestTemplate’ni tushuning
RestClient/WebClient’ni ham bilib qo‘ying
HttpInterface bilan tanishing

7. Example scenario

Tasavvur qilamiz, bizda Product API bor. U tashqi Currency APIdan kurs olib, product narxini USD’dan UZS’ga o‘tkazadi.

Tashqi API taxminan shunday response qaytaradi:

{
  "base": "USD",
  "target": "UZS",
  "rate": 12650.50
}

DTO:

import java.math.BigDecimal;

public record CurrencyRateResponse(
        String base,
        String target,
        BigDecimal rate
) {
}

8. RestTemplate

RestTemplate eski, lekin hali ko‘p loyihalarda uchraydi. Spring hujjatlarida u HTTP request bajaradigan synchronous client sifatida berilgan. (Home)

Dependency

Agar sizda spring-boot-starter-web bo‘lsa, odatda kerakli web client classlar mavjud bo‘ladi.

Bean yaratish

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.client.RestTemplate;

@Configuration
public class RestClientConfig {

    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

GET request

import org.springframework.stereotype.Service;
import org.springframework.web.client.RestTemplate;

@Service
public class CurrencyClient {

    private final RestTemplate restTemplate;

    public CurrencyClient(RestTemplate restTemplate) {
        this.restTemplate = restTemplate;
    }

    public CurrencyRateResponse getUsdToUzsRate() {
        String url = "https://api.example.com/currency/USD/UZS";

        return restTemplate.getForObject(url, CurrencyRateResponse.class);
    }
}

Bu yerda:

getForObject → GET request yuboradi va response body’ni objectga aylantiradi

ResponseEntity bilan olish

Agar status, header ham kerak bo‘lsa:

import org.springframework.http.ResponseEntity;

public CurrencyRateResponse getUsdToUzsRate() {
    String url = "https://api.example.com/currency/USD/UZS";

    ResponseEntity<CurrencyRateResponse> response =
            restTemplate.getForEntity(url, CurrencyRateResponse.class);

    if (!response.getStatusCode().is2xxSuccessful()) {
        throw new BadRequestException("Currency API xato qaytardi");
    }

    return response.getBody();
}

POST request

Masalan SMS servisga request yuboramiz.

Request DTO:

public record SmsSendRequest(
        String phone,
        String message
) {
}

Response DTO:

public record SmsSendResponse(
        String id,
        String status
) {
}

Client:

public SmsSendResponse sendSms(String phone, String message) {
    String url = "https://sms.example.com/api/send";

    SmsSendRequest request = new SmsSendRequest(phone, message);

    return restTemplate.postForObject(
            url,
            request,
            SmsSendResponse.class
    );
}

9. exchange() method

exchange() ko‘proq nazorat beradi: method, headers, body, response type.

import org.springframework.http.*;
import org.springframework.stereotype.Service;

@Service
public class SmsClient {

    private final RestTemplate restTemplate;

    public SmsClient(RestTemplate restTemplate) {
        this.restTemplate = restTemplate;
    }

    public SmsSendResponse sendSms(String phone, String message) {
        String url = "https://sms.example.com/api/send";

        HttpHeaders headers = new HttpHeaders();
        headers.setContentType(MediaType.APPLICATION_JSON);
        headers.setBearerAuth("token-value");

        SmsSendRequest body = new SmsSendRequest(phone, message);

        HttpEntity<SmsSendRequest> entity = new HttpEntity<>(body, headers);

        ResponseEntity<SmsSendResponse> response = restTemplate.exchange(
                url,
                HttpMethod.POST,
                entity,
                SmsSendResponse.class
        );

        return response.getBody();
    }
}

Bu yerda:

HttpHeaders → headerlar
HttpEntity  → body + header
exchange    → to‘liq HTTP request

10. RestTemplate timeout

Timeout juda muhim. Timeout bo‘lmasa, tashqi API osilib qolsa, sizning servis ham kutib qoladi.

Minimal config:

import org.springframework.boot.web.client.RestTemplateBuilder;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.client.RestTemplate;

import java.time.Duration;

@Configuration
public class RestTemplateConfig {

    @Bean
    public RestTemplate restTemplate(RestTemplateBuilder builder) {
        return builder
                .connectTimeout(Duration.ofSeconds(2))
                .readTimeout(Duration.ofSeconds(5))
                .build();
    }
}

Connect timeout

Tashqi serverga ulanish uchun maksimal kutish vaqti

Read timeout

Ulanib bo‘lgandan keyin response kelishini kutish vaqti

Amaliy qoida:

Timeoutsiz HTTP client - production’da xavfli.

11. RestTemplate xatolarini ushlash

RestTemplate 4xx/5xx statuslarda exception tashlashi mumkin.

Masalan:

import org.springframework.web.client.HttpClientErrorException;
import org.springframework.web.client.HttpServerErrorException;
import org.springframework.web.client.ResourceAccessException;

public CurrencyRateResponse getUsdToUzsRate() {
    try {
        return restTemplate.getForObject(
                "https://api.example.com/currency/USD/UZS",
                CurrencyRateResponse.class
        );
    } catch (HttpClientErrorException ex) {
        throw new BadRequestException("Currency API client xato: " + ex.getStatusCode());
    } catch (HttpServerErrorException ex) {
        throw new ExternalServiceException("Currency API server xato");
    } catch (ResourceAccessException ex) {
        throw new ExternalServiceException("Currency API timeout yoki network xato");
    }
}

Custom exception:

public class ExternalServiceException extends RuntimeException {

    public ExternalServiceException(String message) {
        super(message);
    }
}

12. WebClient

WebClient - modern, reactive HTTP client.

Rasmiy Javadoc’da WebClient non-blocking, reactive API ekanligi aytiladi. (Home)

Dependency

WebClient uchun odatda:

implementation 'org.springframework.boot:spring-boot-starter-webflux'

Maven:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-webflux</artifactId>
</dependency>

MVC projectda ham WebClient ishlatish mumkin. Faqat reactive dependency qo‘shiladi.

WebClient bean

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.reactive.function.client.WebClient;

@Configuration
public class WebClientConfig {

    @Bean
    public WebClient currencyWebClient() {
        return WebClient.builder()
                .baseUrl("https://api.example.com")
                .build();
    }
}

GET request

Reactive ko‘rinish:

import org.springframework.stereotype.Service;
import org.springframework.web.reactive.function.client.WebClient;
import reactor.core.publisher.Mono;

@Service
public class CurrencyWebClient {

    private final WebClient webClient;

    public CurrencyWebClient(WebClient currencyWebClient) {
        this.webClient = currencyWebClient;
    }

    public Mono<CurrencyRateResponse> getUsdToUzsRate() {
        return webClient.get()
                .uri("/currency/USD/UZS")
                .retrieve()
                .bodyToMono(CurrencyRateResponse.class);
    }
}

Bu Mono<CurrencyRateResponse> qaytaradi.

MVC projectda .block() ishlatish

Agar siz oddiy Spring MVC projectda bo‘lsangiz va service method oddiy object qaytarishi kerak bo‘lsa:

public CurrencyRateResponse getUsdToUzsRateBlocking() {
    return webClient.get()
            .uri("/currency/USD/UZS")
            .retrieve()
            .bodyToMono(CurrencyRateResponse.class)
            .block();
}

Lekin ehtiyot bo‘ling:

WebFlux reactive flow ichida block() ishlatish yomon.
MVC projectda tashqi API chaqirish uchun ba’zan ishlatiladi.

13. WebClient error handling

import org.springframework.http.HttpStatusCode;
import reactor.core.publisher.Mono;

public Mono<CurrencyRateResponse> getUsdToUzsRate() {
    return webClient.get()
            .uri("/currency/USD/UZS")
            .retrieve()
            .onStatus(
                    HttpStatusCode::is4xxClientError,
                    response -> Mono.error(
                            new BadRequestException("Currency API client xato")
                    )
            )
            .onStatus(
                    HttpStatusCode::is5xxServerError,
                    response -> Mono.error(
                            new ExternalServiceException("Currency API server xato")
                    )
            )
            .bodyToMono(CurrencyRateResponse.class);
}

14. WebClient timeout

Reactor Netty bilan timeout config:

import io.netty.channel.ChannelOption;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.http.client.reactive.ReactorClientHttpConnector;
import org.springframework.web.reactive.function.client.WebClient;
import reactor.netty.http.client.HttpClient;

import java.time.Duration;

@Configuration
public class WebClientConfig {

    @Bean
    public WebClient currencyWebClient() {
        HttpClient httpClient = HttpClient.create()
                .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 2000)
                .responseTimeout(Duration.ofSeconds(5));

        return WebClient.builder()
                .baseUrl("https://api.example.com")
                .clientConnector(new ReactorClientHttpConnector(httpClient))
                .build();
    }
}

Bu yerda:

CONNECT_TIMEOUT_MILLIS → ulanish timeout
responseTimeout       → response kutish timeout

15. WebClient POST request

public Mono<SmsSendResponse> sendSms(String phone, String message) {
    SmsSendRequest request = new SmsSendRequest(phone, message);

    return webClient.post()
            .uri("/api/send")
            .header("Authorization", "Bearer token-value")
            .bodyValue(request)
            .retrieve()
            .bodyToMono(SmsSendResponse.class);
}

Blocking variant:

public SmsSendResponse sendSmsBlocking(String phone, String message) {
    return webClient.post()
            .uri("/api/send")
            .header("Authorization", "Bearer token-value")
            .bodyValue(new SmsSendRequest(phone, message))
            .retrieve()
            .bodyToMono(SmsSendResponse.class)
            .block();
}

16. RestClient

Spring Framework 6.1'dan boshlab RestClient bor. Rasmiy hujjatda RestClient synchronous HTTP client bo‘lib, fluent API orqali request bajarishi aytilgan. (Home)

Bu mavzuda alohida ko‘rsatilmagan, lekin hozirgi Spring loyihalarda bilish foydali.

Bean

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.client.RestClient;

@Configuration
public class RestClientConfig {

    @Bean
    public RestClient currencyRestClient() {
        return RestClient.builder()
                .baseUrl("https://api.example.com")
                .build();
    }
}

GET request

import org.springframework.stereotype.Service;
import org.springframework.web.client.RestClient;

@Service
public class CurrencyRestClient {

    private final RestClient restClient;

    public CurrencyRestClient(RestClient currencyRestClient) {
        this.restClient = currencyRestClient;
    }

    public CurrencyRateResponse getUsdToUzsRate() {
        return restClient.get()
                .uri("/currency/USD/UZS")
                .retrieve()
                .body(CurrencyRateResponse.class);
    }
}

Bu RestTemplatega qaraganda ko‘proq fluent va o‘qilishi qulay.

17. HttpInterface

HttpInterface - declarative HTTP client. Ya’ni siz interface yozasiz, Spring implementation’ni proxy orqali yaratadi.

Rasmiy hujjatlarda HTTP Interface client’lar REST client ustida declarative HTTP service interface yaratish usuli sifatida berilgan. (Home)

Interface

import org.springframework.web.service.annotation.GetExchange;

public interface CurrencyApiClient {

    @GetExchange("/currency/USD/UZS")
    CurrencyRateResponse getUsdToUzsRate();
}

Agar path variable kerak bo‘lsa:

import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.service.annotation.GetExchange;

public interface CurrencyApiClient {

    @GetExchange("/currency/{base}/{target}")
    CurrencyRateResponse getRate(
            @PathVariable String base,
            @PathVariable String target
    );
}

HttpInterface config

Spring 6'da HttpServiceProxyFactory orqali proxy yaratiladi.

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.client.RestClient;
import org.springframework.web.client.support.RestClientAdapter;
import org.springframework.web.service.invoker.HttpServiceProxyFactory;

@Configuration
public class HttpInterfaceConfig {

    @Bean
    public RestClient currencyRestClient() {
        return RestClient.builder()
                .baseUrl("https://api.example.com")
                .build();
    }

    @Bean
    public CurrencyApiClient currencyApiClient(RestClient currencyRestClient) {
        HttpServiceProxyFactory factory = HttpServiceProxyFactory
                .builderFor(RestClientAdapter.create(currencyRestClient))
                .build();

        return factory.createClient(CurrencyApiClient.class);
    }
}

Service’da ishlatish:

@Service
public class CurrencyService {

    private final CurrencyApiClient currencyApiClient;

    public CurrencyService(CurrencyApiClient currencyApiClient) {
        this.currencyApiClient = currencyApiClient;
    }

    public BigDecimal getUsdRate() {
        CurrencyRateResponse response = currencyApiClient.getRate("USD", "UZS");
        return response.rate();
    }
}

18. HttpInterface POST request

import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.service.annotation.PostExchange;

public interface SmsApiClient {

    @PostExchange("/api/send")
    SmsSendResponse sendSms(@RequestBody SmsSendRequest request);
}

Service:

@Service
public class SmsService {

    private final SmsApiClient smsApiClient;

    public SmsService(SmsApiClient smsApiClient) {
        this.smsApiClient = smsApiClient;
    }

    public void sendOrderCreatedSms(String phone) {
        SmsSendResponse response = smsApiClient.sendSms(
                new SmsSendRequest(phone, "Order yaratildi")
        );

        if (!"SUCCESS".equals(response.status())) {
            throw new ExternalServiceException("SMS yuborilmadi");
        }
    }
}

19. Config bilan base URL berish

Hardcode yomon:

.baseUrl("https://api.example.com")

Yaxshiroq:

application.yml:

external:
  currency:
    base-url: https://api.example.com
  sms:
    base-url: https://sms.example.com
    token: ${SMS_TOKEN}

Properties:

import jakarta.validation.constraints.NotBlank;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.validation.annotation.Validated;

@Validated
@ConfigurationProperties(prefix = "external.currency")
public record CurrencyApiProperties(

        @NotBlank
        String baseUrl
) {
}

Config:

@Configuration
@EnableConfigurationProperties(CurrencyApiProperties.class)
public class HttpClientConfig {

    @Bean
    public RestClient currencyRestClient(CurrencyApiProperties properties) {
        return RestClient.builder()
                .baseUrl(properties.baseUrl())
                .build();
    }
}

Bu professionalroq:

URL kodda emas
local/dev/prod’da alohida config bo‘ladi
secret env orqali beriladi

20. Authorization header qo‘shish

Ko‘p tashqi API token talab qiladi.

RestClient bilan

@Bean
public RestClient smsRestClient(SmsApiProperties properties) {
    return RestClient.builder()
            .baseUrl(properties.baseUrl())
            .defaultHeader("Authorization", "Bearer " + properties.token())
            .build();
}

WebClient bilan

@Bean
public WebClient smsWebClient(SmsApiProperties properties) {
    return WebClient.builder()
            .baseUrl(properties.baseUrl())
            .defaultHeader("Authorization", "Bearer " + properties.token())
            .build();
}

21. Timeout har doim bo‘lishi kerak

REST client yozishda eng muhim production qoidalardan biri:

Har bir external API call timeout bilan ishlasin.

Nega?

Agar tashqi SMS servis javob bermasa:

Sizning thread kutib qoladi
Requestlar yig‘iladi
Connection pool to‘ladi
API sekinlashadi
Oxiri service down bo‘lishi mumkin

Timeoutlar:

connect timeout
read/response timeout

Default uchun oddiy qiymatlar:

connect timeout: 1-3 sekund
read timeout: 3-10 sekund

Lekin real qiymat biznesga bog‘liq.

22. Retry nima?

Retry - vaqtinchalik xato bo‘lsa requestni qayta urinish.

Masalan:

1-urinish → network timeout
2-urinish → 503
3-urinish → success

Spring Retry loyihasi Spring applicationlarda declarative retry support berishini rasmiy repository ko‘rsatadi. (GitHub)

Retry qachon kerak?

Retry foydali:

Network glitch
503 Service Unavailable
504 Gateway Timeout
Temporary timeout
Rate limitdan keyin qisqa kutish

Retry xavfli:

Payment charge qilish
Order yaratish
Pul yechish
Duplicate yaratadigan POST request

Muhim qoida:

Retry faqat idempotent yoki xavfsiz operationlarda ishlatilsin.

23. Idempotent nima?

Idempotent operation - bir necha marta chaqirilsa ham natija buzilmaydi.

Odatda:

GET → idempotent
PUT → idempotent bo‘lishi mumkin
DELETE → odatda idempotent bo‘lishi mumkin
POST → ko‘pincha idempotent emas

Masalan:

GET /currency/USD/UZS

Buni retry qilish mumkin.

Lekin:

POST /payments/charge

retry qilinsa, mijozdan ikki marta pul yechilishi mumkin.

Bunday holatda idempotency key kerak bo‘ladi.

24. Spring Retry dependency

Gradle:

implementation 'org.springframework.retry:spring-retry'
implementation 'org.springframework.boot:spring-boot-starter-aop'

Maven:

<dependency>
    <groupId>org.springframework.retry</groupId>
    <artifactId>spring-retry</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-aop</artifactId>
</dependency>

Enable:

import org.springframework.context.annotation.Configuration;
import org.springframework.retry.annotation.EnableRetry;

@Configuration
@EnableRetry
public class RetryConfig {
}

25. @Retryable

import org.springframework.retry.annotation.Backoff;
import org.springframework.retry.annotation.Retryable;

@Service
public class CurrencyService {

    private final CurrencyApiClient currencyApiClient;

    public CurrencyService(CurrencyApiClient currencyApiClient) {
        this.currencyApiClient = currencyApiClient;
    }

    @Retryable(
            retryFor = ExternalServiceException.class,
            maxAttempts = 3,
            backoff = @Backoff(delay = 1000)
    )
    public CurrencyRateResponse getUsdToUzsRate() {
        return currencyApiClient.getRate("USD", "UZS");
    }
}

Ma’nosi:

ExternalServiceException chiqsa retry qil
Maksimal 3 marta urinsin
Har urinish orasida 1 sekund kutadi

@Recover

Agar retrylar ham muvaffaqiyatsiz bo‘lsa:

import org.springframework.retry.annotation.Recover;

@Recover
public CurrencyRateResponse recover(ExternalServiceException ex) {
    throw new ExternalServiceException("Currency API vaqtincha ishlamayapti");
}

Yoki fallback qiymat qaytarish mumkin, lekin ehtiyot bo‘ling:

@Recover
public CurrencyRateResponse recover(ExternalServiceException ex) {
    return new CurrencyRateResponse(
            "USD",
            "UZS",
            BigDecimal.valueOf(12600)
    );
}

Bu biznesga bog‘liq. Moliyaviy kurslarda eski qiymat qaytarish xavfli bo‘lishi mumkin.

26. Retry’ni haddan oshirmang

Yomon:

maxAttempts = 10
delay = 0

Bu tashqi servisga yana ko‘proq bosim beradi.

Yaxshi:

maxAttempts = 2 yoki 3
delay = 500ms / 1s
exponential backoff

Retry sababli umumiy request latency ham oshadi.

Masalan:

timeout 5s
retry 3 marta
jami kutish 15s+ bo‘lishi mumkin

Shuning uchun timeout va retry birga o‘ylanishi kerak.

27. External API response’ni ichki API response’dan ajrating

Tashqi API DTO’sini ichki response sifatida qaytarmang.

Yomon:

@GetMapping("/rate")
public CurrencyRateResponse getRate() {
    return currencyClient.getUsdToUzsRate();
}

Yaxshiroq:

public record ProductPriceResponse(
        Long productId,
        BigDecimal priceUsd,
        BigDecimal priceUzs
) {
}

Service:

public ProductPriceResponse getProductPriceInUzs(Long productId) {
    Product product = productRepository.findById(productId)
            .orElseThrow(() -> new NotFoundException("Product topilmadi"));

    CurrencyRateResponse rate = currencyClient.getUsdToUzsRate();

    BigDecimal priceUzs = product.getPriceUsd().multiply(rate.rate());

    return new ProductPriceResponse(
            product.getId(),
            product.getPriceUsd(),
            priceUzs
    );
}

Sabab:

External API o‘zgarsa, sizning public API buzilmasin.

28. ExternalServiceException handler

Oldingi exception handling darsiga qo‘shamiz.

public class ExternalServiceException extends RuntimeException {

    public ExternalServiceException(String message) {
        super(message);
    }
}

Global handler:

@ExceptionHandler(ExternalServiceException.class)
public ResponseEntity<ErrorResponse> handleExternalService(
        ExternalServiceException ex,
        HttpServletRequest request
) {
    ErrorResponse response = new ErrorResponse(
            "EXTERNAL_SERVICE_ERROR",
            ex.getMessage(),
            HttpStatus.BAD_GATEWAY.value(),
            request.getRequestURI(),
            LocalDateTime.now(),
            null
    );

    return ResponseEntity
            .status(HttpStatus.BAD_GATEWAY)
            .body(response);
}

Nega 502 Bad Gateway?

Chunki sizning API ishlayapti, lekin upstream/tashqi service bilan muammo bor.

29. Logging

External call xatolarini log qilish kerak.

private static final Logger log =
        LoggerFactory.getLogger(CurrencyClient.class);

public CurrencyRateResponse getUsdToUzsRate() {
    try {
        return restClient.get()
                .uri("/currency/USD/UZS")
                .retrieve()
                .body(CurrencyRateResponse.class);
    } catch (Exception ex) {
        log.error("Currency API call failed", ex);
        throw new ExternalServiceException("Currency API vaqtincha ishlamayapti");
    }
}

Lekin token, password, secretlarni log qilmang.

Yomon:

log.info("SMS token: {}", token);

Mutlaqo qilinmaydi.

30. Observability uchun nima log qilish kerak?

Yaxshi log:

external service nomi
endpoint nomi
status code
duration
correlation id / trace id

Yomon log:

token
password
full card number
secret key
shaxsiy ma’lumotlar

31. Product API bilan to‘liq misol

application.yml

external:
  currency:
    base-url: https://api.example.com
    connect-timeout-ms: 2000
    read-timeout-ms: 5000

Properties

import jakarta.validation.constraints.Min;
import jakarta.validation.constraints.NotBlank;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.validation.annotation.Validated;

@Validated
@ConfigurationProperties(prefix = "external.currency")
public record CurrencyApiProperties(

        @NotBlank
        String baseUrl,

        @Min(100)
        int connectTimeoutMs,

        @Min(100)
        int readTimeoutMs
) {
}

RestClient config

@Configuration
@EnableConfigurationProperties(CurrencyApiProperties.class)
public class CurrencyClientConfig {

    @Bean
    public RestClient currencyRestClient(CurrencyApiProperties properties) {
        return RestClient.builder()
                .baseUrl(properties.baseUrl())
                .build();
    }
}

Interface

public interface CurrencyClient {

    CurrencyRateResponse getRate(String base, String target);
}

Implementation

import org.springframework.stereotype.Component;
import org.springframework.web.client.RestClient;

@Component
public class CurrencyRestClientImpl implements CurrencyClient {

    private final RestClient restClient;

    public CurrencyRestClientImpl(RestClient currencyRestClient) {
        this.restClient = currencyRestClient;
    }

    @Override
    public CurrencyRateResponse getRate(String base, String target) {
        try {
            return restClient.get()
                    .uri("/currency/{base}/{target}", base, target)
                    .retrieve()
                    .body(CurrencyRateResponse.class);
        } catch (Exception ex) {
            throw new ExternalServiceException("Currency API vaqtincha ishlamayapti");
        }
    }
}

Product service

@Service
public class ProductPriceService {

    private final ProductRepository productRepository;
    private final CurrencyClient currencyClient;

    public ProductPriceService(ProductRepository productRepository,
                               CurrencyClient currencyClient) {
        this.productRepository = productRepository;
        this.currencyClient = currencyClient;
    }

    @Transactional(readOnly = true)
    public ProductPriceResponse getPriceInUzs(Long productId) {
        Product product = productRepository.findById(productId)
                .orElseThrow(() -> new NotFoundException("Product topilmadi"));

        CurrencyRateResponse rate = currencyClient.getRate("USD", "UZS");

        BigDecimal priceUzs = product.getPriceUsd().multiply(rate.rate());

        return new ProductPriceResponse(
                product.getId(),
                product.getPriceUsd(),
                priceUzs
        );
    }
}

32. Testing: tashqi API’ni real chaqirmang

Unit testda haqiqiy SMS yoki currency API chaqirish yomon.

Nega?

Test sekinlashadi
Internet kerak bo‘ladi
External API limit tugashi mumkin
Pullik SMS ketib qolishi mumkin
Test beqaror bo‘ladi

Yaxshiroq:

CurrencyClient mock qilinadi
WireMock ishlatiladi
MockWebServer ishlatiladi

Boshlanishiga kamida interface orqali ajratishni biling:

public interface CurrencyClient {
    CurrencyRateResponse getRate(String base, String target);
}

Testda fake implementation berish mumkin.

33. Ko‘p uchraydigan xatolar

Xato 1: Timeout qo‘ymaslik

Yomon:

new RestTemplate()

Yaxshi:

builder
    .connectTimeout(Duration.ofSeconds(2))
    .readTimeout(Duration.ofSeconds(5))
    .build()

Xato 2: Tokenni hardcode qilish

Yomon:

.header("Authorization", "Bearer abc123")

Yaxshi:

sms:
  token: ${SMS_TOKEN}

Xato 3: Har joyda client yaratish

Yomon:

public void send() {
    RestTemplate restTemplate = new RestTemplate();
}

Yaxshi:

@Bean
public RestTemplate restTemplate() {}

Yoki:

@Bean
public RestClient restClient() {}

Xato 4: External API DTO’sini domain modeli qilib ishlatish

Yomon:

ProductService external API response’ga to‘liq bog‘lanib qoladi

Yaxshi:

External DTO → Client layer
Internal DTO/domain → Service/API layer

Xato 5: Har bir xatoda retry qilish

Yomon:

400 Bad Request bo‘lsa ham retry
401 Unauthorized bo‘lsa ham retry
403 Forbidden bo‘lsa ham retry

Bular retry bilan tuzalmaydi.

Retry ko‘proq:

timeout
503
temporary network error

uchun.

Xato 6: Payment POST requestni retry qilish

Bu juda xavfli bo‘lishi mumkin.

1-request pul yechdi, lekin response kelmadi
retry yana pul yechdi

Bunday holatda idempotency key ishlatiladi.

34. Java developer uchun qisqa qoida

RestTemplate → legacy blocking client
RestClient → modern blocking client
WebClient → reactive/non-blocking client
HttpInterface → declarative client
Timeout → majburiy
Retry → faqat vaqtinchalik va xavfsiz xatolarda
ExternalServiceException → tashqi servis xatolari uchun
Config → base URL va token kodda emas

35. Amaliy vazifa

Oldingi Product CRUD API loyihasiga external currency client qo‘shing.

Talablar

Config

external:
  currency:
    base-url: https://api.example.com
    connect-timeout-ms: 2000
    read-timeout-ms: 5000

DTO

public record CurrencyRateResponse(
        String base,
        String target,
        BigDecimal rate
) {
}

public record ProductPriceResponse(
        Long productId,
        BigDecimal priceUsd,
        BigDecimal priceUzs
) {
}

Client

CurrencyClient interface
CurrencyRestClientImpl implementation

Service

ProductPriceService productni topadi
CurrencyClient orqali USD→UZS kurs oladi
priceUzs hisoblaydi

Exception

ExternalServiceException
GlobalExceptionHandler → 502 Bad Gateway

Muhim qoida

Currency API ishlamasa, clientga 500 emas, 502 qaytaring.
Timeout qo‘ying.
Base URL configdan olinsin.

Xulosa

REST client & HTTP mavzusida Java developer quyidagilarni bilishi kerak:

HTTP methodlar va status codelar
RestTemplate
WebClient
RestClient
HttpInterface
GET / POST request yuborish
Header qo‘shish
Bearer token yuborish
Timeout config
Retry config
ExternalServiceException
502 Bad Gateway
External DTO va internal DTO ajratish

Eng muhim professional qoida:

Tashqi API chaqiruvi hech qachon timeout, error handling va configsiz yozilmaydi.

1. REST API nima?

REST API - frontend, mobile app yoki boshqa servis backend bilan gaplashishi uchun ishlatiladigan HTTP API.

Masalan, mobil app backenddan userlar ro‘yxatini so‘raydi:

GET /users

Backend javob qaytaradi:

[
  {
    "id": 1,
    "name": "Ali"
  },
  {
    "id": 2,
    "name": "Vali"
  }
]

Oddiy qilib:

REST API - client va server o‘rtasidagi kelishilgan HTTP muloqot.

2. REST API qayerda ishlatiladi?

Masalan:

Android app → Spring Boot API
iOS app     → Spring Boot API
React app   → Spring Boot API
Telegram bot → Spring Boot API
Boshqa microservice → Spring Boot API

Backend odatda JSON qaytaradi.

3. HTTP methodlar

REST API’da eng ko‘p ishlatiladigan methodlar:

4. Birinchi controller

Spring Boot’da REST API yozish uchun @RestController ishlatiladi.

@RestController
public class HelloController {

    @GetMapping("/hello")
    public String hello() {
        return "Salom Spring Boot";
    }
}

Brauzerda ochamiz:

http://localhost:8080/hello

Natija:

Salom Spring Boot

5. @RestController nima?

@RestController - bu class REST API controller ekanini bildiradi.

Ya’ni:

@RestController
public class UserController {
}

Spring bu classni HTTP request qabul qiladigan controller sifatida ko‘radi.

Muhim jihati:

@RestController methoddan qaytgan qiymatni avtomatik HTTP response body qilib beradi.

Masalan:

@GetMapping("/name")
public String name() {
    return "Ali";
}

Javob body:

Ali

6. @RequestMapping nima?

@RequestMapping umumiy path berish uchun ishlatiladi.

Masalan:

@RestController
@RequestMapping("/users")
public class UserController {
}

Endi shu controller ichidagi hamma endpoint /users bilan boshlanadi.

@GetMapping
public String getUsers() {
    return "Users list";
}

Full path:

GET /users

7. @GetMapping

GET - ma’lumot olish uchun.

@RestController
@RequestMapping("/users")
public class UserController {

    @GetMapping
    public String getUsers() {
        return "Userlar ro'yxati";
    }
}

Request:

GET /users

Response:

Userlar ro'yxati

8. @PostMapping

POST - yangi ma’lumot yaratish uchun.

@PostMapping
public String createUser() {
    return "User yaratildi";
}

Request:

POST /users

Response:

User yaratildi

Lekin real loyihada POST odatda body bilan keladi.

9. @PutMapping

PUT - mavjud ma’lumotni yangilash uchun.

@PutMapping("/{id}")
public String updateUser(@PathVariable Long id) {
    return "User yangilandi: " + id;
}

Request:

PUT /users/5

Response:

User yangilandi: 5

10. @DeleteMapping

DELETE - ma’lumotni o‘chirish uchun.

@DeleteMapping("/{id}")
public String deleteUser(@PathVariable Long id) {
    return "User o'chirildi: " + id;
}

Request:

DELETE /users/5

Response:

User o'chirildi: 5

11. To‘liq CRUD endpointlar

@RestController
@RequestMapping("/users")
public class UserController {

    @GetMapping
    public String getUsers() {
        return "Barcha userlar";
    }

    @GetMapping("/{id}")
    public String getUserById(@PathVariable Long id) {
        return "User ID: " + id;
    }

    @PostMapping
    public String createUser() {
        return "User yaratildi";
    }

    @PutMapping("/{id}")
    public String updateUser(@PathVariable Long id) {
        return "User yangilandi: " + id;
    }

    @DeleteMapping("/{id}")
    public String deleteUser(@PathVariable Long id) {
        return "User o'chirildi: " + id;
    }
}

Endpointlar:

GET    /users
GET    /users/1
POST   /users
PUT    /users/1
DELETE /users/1

12. @PathVariable nima?

@PathVariable - URL ichidagi qiymatni olish uchun ishlatiladi.

Masalan:

GET /users/10

Bu yerda 10 - path variable.

Kod:

@GetMapping("/{id}")
public String getUser(@PathVariable Long id) {
    return "User ID: " + id;
}

Natija:

User ID: 10

@PathVariable nomi boshqacha bo‘lsa

@GetMapping("/{userId}")
public String getUser(@PathVariable Long userId) {
    return "User ID: " + userId;
}

Yoki aniq ko‘rsatish mumkin:

@GetMapping("/{id}")
public String getUser(@PathVariable("id") Long userId) {
    return "User ID: " + userId;
}

13. @RequestParam nima?

@RequestParam - URL query parameter olish uchun ishlatiladi.

Masalan:

GET /users?name=Ali

Kod:

@GetMapping("/search")
public String searchUser(@RequestParam String name) {
    return "Qidirilgan user: " + name;
}

Request:

GET /users/search?name=Ali

Response:

Qidirilgan user: Ali

Bir nechta @RequestParam

GET /users/search?name=Ali&age=25

@GetMapping("/search")
public String searchUser(
        @RequestParam String name,
        @RequestParam Integer age
) {
    return name + " - " + age;
}

Optional @RequestParam

Agar parameter kelmasa ham xato bermasin desak:

@GetMapping("/search")
public String searchUser(
        @RequestParam(required = false) String name
) {
    return "Name: " + name;
}

Default qiymat berish:

@GetMapping("/search")
public String searchUser(
        @RequestParam(defaultValue = "unknown") String name
) {
    return "Name: " + name;
}

14. @PathVariable vs @RequestParam

Qachon qaysi biri?

/users/5             → aniq bitta user olish → @PathVariable
/users?name=Ali      → filter/search qilish → @RequestParam
/users?page=1&size=20 → pagination → @RequestParam

15. @RequestBody nima?

@RequestBody - HTTP request body ichidagi JSON’ni Java objectga aylantirib beradi.

Masalan frontend shunday JSON yuboradi:

{
  "name": "Ali",
  "age": 25
}

Biz Java’da DTO class yozamiz:

public class CreateUserRequest {

    private String name;
    private Integer age;

    public String getName() {
        return name;
    }

    public Integer getAge() {
        return age;
    }

    public void setName(String name) {
        this.name = name;
    }

    public void setAge(Integer age) {
        this.age = age;
    }
}

Controller:

@PostMapping
public String createUser(@RequestBody CreateUserRequest request) {
    return "User yaratildi: " + request.getName();
}

Request:

POST /users
Content-Type: application/json

Body:

{
  "name": "Ali",
  "age": 25
}

Response:

User yaratildi: Ali

16. Lombok bilan DTO

Agar Lombok ishlatsak:

@Getter
@Setter
public class CreateUserRequest {
    private String name;
    private Integer age;
}

Yoki Java record:

public record CreateUserRequest(
        String name,
        Integer age
) {
}

Spring Boot’da record DTO uchun juda qulay.

17. Response object qaytarish

Text emas, object qaytarsak, Spring avtomatik JSON qiladi.

public record UserResponse(
        Long id,
        String name,
        Integer age
) {
}

Controller:

@GetMapping("/{id}")
public UserResponse getUser(@PathVariable Long id) {
    return new UserResponse(id, "Ali", 25);
}

Response:

{
  "id": 1,
  "name": "Ali",
  "age": 25
}

18. List qaytarish

@GetMapping
public List<UserResponse> getUsers() {
    return List.of(
            new UserResponse(1L, "Ali", 25),
            new UserResponse(2L, "Vali", 30)
    );
}

Response:

[
  {
    "id": 1,
    "name": "Ali",
    "age": 25
  },
  {
    "id": 2,
    "name": "Vali",
    "age": 30
  }
]

19. ResponseEntity nima?

ResponseEntity - HTTP response’ni to‘liq nazorat qilish uchun ishlatiladi.

U orqali quyidagilarni belgilaymiz:

Response body
HTTP status code
Header

Oddiy misol:

@GetMapping("/{id}")
public ResponseEntity<UserResponse> getUser(@PathVariable Long id) {
    UserResponse response = new UserResponse(id, "Ali", 25);
    return ResponseEntity.ok(response);
}

Bu:

HTTP status: 200 OK
Body: user JSON

20. 201 Created qaytarish

Yangi resource yaratilganda 201 Created qaytarish yaxshi.

@PostMapping
public ResponseEntity<UserResponse> createUser(
        @RequestBody CreateUserRequest request
) {
    UserResponse response = new UserResponse(1L, request.name(), request.age());

    return ResponseEntity
            .status(HttpStatus.CREATED)
            .body(response);
}

Response:

HTTP status: 201 Created

Body:

{
  "id": 1,
  "name": "Ali",
  "age": 25
}

21. 204 No Content qaytarish

Delete qilinganda ko‘pincha body qaytarilmaydi.

@DeleteMapping("/{id}")
public ResponseEntity<Void> deleteUser(@PathVariable Long id) {
    return ResponseEntity.noContent().build();
}

Response:

HTTP status: 204 No Content
Body yo‘q

22. HTTP status codes

Eng kerakli statuslar:

23. To‘liq mini REST API

UserResponse

public record UserResponse(
        Long id,
        String name,
        Integer age
) {
}

CreateUserRequest

public record CreateUserRequest(
        String name,
        Integer age
) {
}

UserController

@RestController
@RequestMapping("/users")
public class UserController {

    @GetMapping
    public List<UserResponse> getUsers() {
        return List.of(
                new UserResponse(1L, "Ali", 25),
                new UserResponse(2L, "Vali", 30)
        );
    }

    @GetMapping("/{id}")
    public ResponseEntity<UserResponse> getUser(@PathVariable Long id) {
        UserResponse response = new UserResponse(id, "Ali", 25);
        return ResponseEntity.ok(response);
    }

    @PostMapping
    public ResponseEntity<UserResponse> createUser(
            @RequestBody CreateUserRequest request
    ) {
        UserResponse response = new UserResponse(3L, request.name(), request.age());

        return ResponseEntity
                .status(HttpStatus.CREATED)
                .body(response);
    }

    @PutMapping("/{id}")
    public ResponseEntity<UserResponse> updateUser(
            @PathVariable Long id,
            @RequestBody CreateUserRequest request
    ) {
        UserResponse response = new UserResponse(id, request.name(), request.age());
        return ResponseEntity.ok(response);
    }

    @DeleteMapping("/{id}")
    public ResponseEntity<Void> deleteUser(@PathVariable Long id) {
        return ResponseEntity.noContent().build();
    }
}

24. Postman yoki browser orqali test

Browser bilan

Browser faqat GET endpointlarni oson test qiladi:

http://localhost:8080/users
http://localhost:8080/users/1

Postman bilan

POST, PUT, DELETE uchun Postman ishlatish qulay.

POST request:

POST http://localhost:8080/users
Content-Type: application/json

Body:

{
  "name": "Hasan",
  "age": 22
}

Expected response:

{
  "id": 3,
  "name": "Hasan",
  "age": 22
}

Status:

201 Created

25. curl bilan test

Terminalda:

curl http://localhost:8080/users

POST:

curl -X POST http://localhost:8080/users \
  -H "Content-Type: application/json" \
  -d '{"name":"Hasan","age":22}'

PUT:

curl -X PUT http://localhost:8080/users/1 \
  -H "Content-Type: application/json" \
  -d '{"name":"Ali Updated","age":26}'

DELETE:

curl -X DELETE http://localhost:8080/users/1

26. Controller → Service → Repository qilish

Bo'shlanishiga controller ichida hamma narsani yozib ketish mumkin, lekin real loyihada bu noto‘g‘ri.

Yaxshi structure:

controller → service → repository

Masalan:

UserController request oladi
UserService biznes logika bajaradi
UserRepository data bilan ishlaydi

UserService

@Service
public class UserService {

    public List<UserResponse> getUsers() {
        return List.of(
                new UserResponse(1L, "Ali", 25),
                new UserResponse(2L, "Vali", 30)
        );
    }

    public UserResponse getUser(Long id) {
        return new UserResponse(id, "Ali", 25);
    }

    public UserResponse createUser(CreateUserRequest request) {
        return new UserResponse(3L, request.name(), request.age());
    }
}

UserController

@RestController
@RequestMapping("/users")
public class UserController {

    private final UserService userService;

    public UserController(UserService userService) {
        this.userService = userService;
    }

    @GetMapping
    public List<UserResponse> getUsers() {
        return userService.getUsers();
    }

    @GetMapping("/{id}")
    public ResponseEntity<UserResponse> getUser(@PathVariable Long id) {
        return ResponseEntity.ok(userService.getUser(id));
    }

    @PostMapping
    public ResponseEntity<UserResponse> createUser(
            @RequestBody CreateUserRequest request
    ) {
        return ResponseEntity
                .status(HttpStatus.CREATED)
                .body(userService.createUser(request));
    }
}

Bu yaxshiroq, chunki controller faqat request/response bilan ishlaydi.

27. Eng ko‘p xatolar

1. @RestController yozmaslik

Xato:

public class UserController {
}

To‘g‘ri:

@RestController
public class UserController {
}

2. @RequestBody unutish

Xato:

@PostMapping
public String createUser(CreateUserRequest request) {
    return request.name();
}

To‘g‘ri:

@PostMapping
public String createUser(@RequestBody CreateUserRequest request) {
    return request.name();
}

3. Content-Type bermaslik

POST request yuborganda header kerak:

Content-Type: application/json

Aks holda Spring body’ni to‘g‘ri o‘qimasligi mumkin.

4. Path nomlari chalkashishi

Xato:

@GetMapping("/{id}")
public String getUser(@PathVariable Long userId) {
    return userId.toString();
}

Bu holatda Spring ba’zan id bilan userIdni moslay olmaydi.

To‘g‘ri:

@GetMapping("/{id}")
public String getUser(@PathVariable("id") Long userId) {
    return userId.toString();
}

28. REST API naming qoidalari

Yaxshi endpointlar:

GET    /users
GET    /users/1
POST   /users
PUT    /users/1
DELETE /users/1

Yomonroq endpointlar:

GET /getUsers
POST /createUser
POST /deleteUser
GET /userDelete

REST’da odatda fe’l emas, resource nomi ishlatiladi:

/users
/products
/orders
/payments

Amalni HTTP method bildiradi:

GET    → olish
POST   → yaratish
PUT    → yangilash
DELETE → o‘chirish

29. Interview uchun javoblar

Savol: @RestController nima?

@RestController Spring’da REST API controller yaratish uchun ishlatiladi. U methoddan qaytgan qiymatni avtomatik HTTP response body qilib qaytaradi.

Savol: @PathVariable va @RequestParam farqi?

@PathVariable URL path ichidagi qiymatni oladi, masalan /users/1. @RequestParam esa query parameter oladi, masalan /users?name=Ali.

Savol: @RequestBody nima?

@RequestBody HTTP request body ichidagi JSON’ni Java obyektga convert qilib beradi.

Savol: ResponseEntity nima uchun kerak?

ResponseEntity response body, HTTP status code va headerlarni boshqarish uchun kerak.

30. Bo'shlangich java developer uchun xulosa

Bugungi mavzudan eslab qoling:

@RestController - REST API controller
@RequestMapping - umumiy path
@GetMapping - ma’lumot olish
@PostMapping - yangi ma’lumot yaratish
@PutMapping - ma’lumot yangilash
@DeleteMapping - ma’lumot o‘chirish
@PathVariable - URL pathdan qiymat olish
@RequestParam - query parameter olish
@RequestBody - JSON body olish
ResponseEntity - status/body/header boshqarish

31. Amaliy vazifa

Product API yoz:

GET    /products
GET    /products/1
POST   /products
PUT    /products/1
DELETE /products/1

DTO:

public record ProductRequest(
        String name,
        Double price
) {
}

Response:

public record ProductResponse(
        Long id,
        String name,
        Double price
) {
}

Controller service orqali ishlasin:

ProductController → ProductService

1. Layered Architecture nima?

Layered architecture - bu loyihani bir nechta qatlamlarga ajratib yozish usuli.

Oddiy qilib aytganda:

Client / Frontend / Mobile App
        ↓
Controller
        ↓
Service
        ↓
Repository
        ↓
Database

Har bir qatlamning o‘z vazifasi bor. Hammasini bitta joyga yozib yubormaymiz.

2. Nega Layered Architecture kerak?

Agar hamma kodni bitta Controller ichiga yozsak, loyiha tez buziladi.

Masalan:

@RestController
public class UserController {

    @PostMapping("/users")
    public User createUser(@RequestBody User user) {
        // validation
        // business logic
        // database save
        // response qaytarish
    }
}

Bu yomon uslub. Chunki Controller ichida hamma narsa aralashib ketadi:

• HTTP request qabul qilish

• ma’lumot tekshirish

• biznes qoida

• database bilan ishlash

• response qaytarish

Kichik loyiha bo‘lsa ham ishlaydi. Lekin real loyihada bu kodni tushunish, test qilish, o‘zgartirish qiyinlashadi.

3. Asosiy qatlamlar

3.1 Controller layer

Controller - tashqi dunyo bilan aloqa qiladigan qatlam.

Frontend, mobile app yoki Postman request yuboradi. Controller shu requestni qabul qiladi.

@RestController
@RequestMapping("/api/users")
public class UserController {

    private final UserService userService;

    public UserController(UserService userService) {
        this.userService = userService;
    }

    @PostMapping
    public UserResponse create(@RequestBody UserCreateRequest request) {
        return userService.create(request);
    }
}

Controller vazifasi:

• request qabul qilish

• request body olish

• path variable olish

• query param olish

• service chaqirish

• response qaytarish

Controller qilmasligi kerak:

• databasega to‘g‘ridan-to‘g‘ri murojaat qilmasligi kerak

• biznes logic yozmasligi kerak

• murakkab hisob-kitob qilmasligi kerak

Yomon misol:

@PostMapping
public User create(@RequestBody User user) {
    if (user.getAge() < 18) {
        throw new RuntimeException("User must be adult");
    }

    return userRepository.save(user);
}

Bu noto‘g‘ri. Chunki controller ichida business logic va repository ishlatilgan.

3.2 Service layer

Service - biznes logic yoziladigan joy.

Masalan:

• foydalanuvchi yaratish

• buyurtma hisoblash

• chegirma qo‘llash

• balansni tekshirish

• transaction boshqarish

• bir nechta repository bilan ishlash

@Service
public class UserService {

    private final UserRepository userRepository;
    private final UserMapper userMapper;

    public UserService(UserRepository userRepository, UserMapper userMapper) {
        this.userRepository = userRepository;
        this.userMapper = userMapper;
    }

    public UserResponse create(UserCreateRequest request) {
        if (request.age() < 18) {
            throw new IllegalArgumentException("User must be adult");
        }

        User user = userMapper.toEntity(request);
        User savedUser = userRepository.save(user);

        return userMapper.toResponse(savedUser);
    }
}

Service vazifasi:

• business logic

• tekshiruvlar

• repository chaqirish

• transaction boshqarish

• entity va DTO o‘rtasida ishlash

Service qilmasligi kerak:

• HTTP status code bilan ko‘p ishlamasligi kerak

• @RequestBody, @PathVariable kabi web annotationlarga bog‘lanmasligi kerak

• frontend formatiga haddan tashqari bog‘lanmasligi kerak

3.3 Repository layer

Repository - database bilan ishlaydigan qatlam.

Spring Data JPA’da odatda interface bo‘ladi:

@Repository
public interface UserRepository extends JpaRepository<User, Long> {

    boolean existsByEmail(String email);

    Optional<User> findByEmail(String email);
}

Repository vazifasi:

• databasega yozish

• database’dan o‘qish

• query bajarish

• entity bilan ishlash

Repository qilmasligi kerak:

• business logic yozmasligi kerak

• DTO qaytarmasligi afzal

• HTTP bilan aloqasi bo‘lmasligi kerak

4. Entity nima?

Entity - database jadvaliga mos keladigan Java class.

@Entity
@Table(name = "users")
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String fullName;

    private String email;

    private Integer age;

    // getters/setters
}

Bu class database bilan bog‘langan.

Masalan jadval:

users
-----
id
full_name
email
age

Entity asosan Repository va Service qatlamida ishlatiladi.

5. DTO nima?

DTO - Data Transfer Object.

Bu client bilan ma’lumot almashish uchun ishlatiladigan class.

Masalan request DTO:

public record UserCreateRequest(
        String fullName,
        String email,
        Integer age
) {
}

Response DTO:

public record UserResponse(
        Long id,
        String fullName,
        String email
) {
}

Bu yerda age response’da qaytmayapti. Chunki clientga hamma ma’lumotni berish shart emas.

6. DTO vs Entity - nima uchun ajratamiz?

Entity’ni to‘g‘ridan-to‘g‘ri API’da ishlatish yomon

Yomon misol:

@PostMapping
public User create(@RequestBody User user) {
    return userRepository.save(user);
}

Nega yomon?

Chunki User entity ichida databasega oid fieldlar bor. Masalan:

private String password;
private Boolean deleted;
private LocalDateTime createdAt;
private LocalDateTime updatedAt;

Agar entity’ni response qilib qaytarsangiz, noxush holat bo‘lishi mumkin:

{
  "id": 1,
  "fullName": "Ali Valiyev",
  "email": "ali@mail.com",
  "password": "123456",
  "deleted": false
}

Bu xavfli.

Shuning uchun:

Request DTO → Service → Entity → Repository
Repository → Entity → Service → Response DTO

7. Mapping nima?

Mapping - DTO’dan Entity yasash yoki Entity’dan DTO yasash.

Masalan manual mapping:

@Component
public class UserMapper {

    public User toEntity(UserCreateRequest request) {
        User user = new User();
        user.setFullName(request.fullName());
        user.setEmail(request.email());
        user.setAge(request.age());
        return user;
    }

    public UserResponse toResponse(User user) {
        return new UserResponse(
                user.getId(),
                user.getFullName(),
                user.getEmail()
        );
    }
}

Bu oddiy va tushunarli usul.

Katta loyihalarda MapStruct ishlatiladi.

8. To‘liq oqim qanday ishlaydi?

Masalan frontend request yuboradi:

POST /api/users
Content-Type: application/json

{
  "fullName": "Ali Valiyev",
  "email": "ali@mail.com",
  "age": 22
}

Spring Boot’da oqim:

1. UserController requestni oladi
2. UserController UserService.create() chaqiradi
3. UserService biznes qoidani tekshiradi
4. UserService DTO’ni Entity’ga aylantiradi
5. UserRepository databasega saqlaydi
6. Service Entity’ni Response DTO’ga aylantiradi
7. Controller response qaytaradi

Natija:

{
  "id": 1,
  "fullName": "Ali Valiyev",
  "email": "ali@mail.com"
}

9. @Transactional qayerga qo‘yiladi?

@Transactional odatda Service layerga qo‘yiladi.

Masalan:

@Service
public class OrderService {

    private final OrderRepository orderRepository;
    private final PaymentRepository paymentRepository;

    public OrderService(OrderRepository orderRepository,
                        PaymentRepository paymentRepository) {
        this.orderRepository = orderRepository;
        this.paymentRepository = paymentRepository;
    }

    @Transactional
    public void createOrder(CreateOrderRequest request) {
        orderRepository.save(new Order(...));
        paymentRepository.save(new Payment(...));
    }
}

Nega service layer?

Chunki transaction odatda bitta repository emas, butun business operation uchun kerak bo‘ladi.

Masalan:

Order save bo‘ldi
Payment save bo‘lmadi

Bunday holatda hammasi rollback bo‘lishi kerak. Ya’ni order ham saqlanmasligi kerak.

Shu sabab @Transactional repositoryga emas, service methodga qo‘yiladi.

10. Package-by-layer

Bu eng oddiy struktura:

src/main/java/com/example/demo
 ├── controller
 │    └── UserController.java
 ├── service
 │    └── UserService.java
 ├── repository
 │    └── UserRepository.java
 ├── entity
 │    └── User.java
 ├── dto
 │    ├── UserCreateRequest.java
 │    └── UserResponse.java
 └── mapper
      └── UserMapper.java

Bu boshlang'ich uchun yaxshi boshlanish.

Afzalligi:

• tushunish oson

• Spring Boot tutoriallarda ko‘p uchraydi

• kichik loyihalar uchun qulay

Kamchiligi:

• loyiha kattalashsa, fayllar juda ko‘payadi

• user, order, product kodlari har xil papkalarga sochilib ketadi

11. Package-by-feature

Bu real loyihalarda ko‘proq qulay bo‘ladi.

src/main/java/com/example/demo
 ├── user
 │    ├── UserController.java
 │    ├── UserService.java
 │    ├── UserRepository.java
 │    ├── User.java
 │    ├── UserCreateRequest.java
 │    ├── UserResponse.java
 │    └── UserMapper.java
 ├── order
 │    ├── OrderController.java
 │    ├── OrderService.java
 │    ├── OrderRepository.java
 │    └── Order.java
 └── product
      ├── ProductController.java
      ├── ProductService.java
      ├── ProductRepository.java
      └── Product.java

Afzalligi:

• bitta feature’ga oid kod bitta joyda turadi

• katta loyihada qulay

• domain bo‘yicha tartibli bo‘ladi

Java developer sifatida ikkalasini bilish kerak.

Amaliy maslahat:

Kichik o‘quv loyiha → package-by-layer
Real loyiha yoki katta loyiha → package-by-feature

12. To‘liq mini misol

Entity

@Entity
@Table(name = "users")
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String fullName;

    private String email;

    private Integer age;

    // getters/setters
}

DTO

public record UserCreateRequest(
        String fullName,
        String email,
        Integer age
) {
}

public record UserResponse(
        Long id,
        String fullName,
        String email
) {
}

Repository

public interface UserRepository extends JpaRepository<User, Long> {

    boolean existsByEmail(String email);
}

Mapper

@Component
public class UserMapper {

    public User toEntity(UserCreateRequest request) {
        User user = new User();
        user.setFullName(request.fullName());
        user.setEmail(request.email());
        user.setAge(request.age());
        return user;
    }

    public UserResponse toResponse(User user) {
        return new UserResponse(
                user.getId(),
                user.getFullName(),
                user.getEmail()
        );
    }
}

Service

@Service
public class UserService {

    private final UserRepository userRepository;
    private final UserMapper userMapper;

    public UserService(UserRepository userRepository,
                       UserMapper userMapper) {
        this.userRepository = userRepository;
        this.userMapper = userMapper;
    }

    @Transactional
    public UserResponse create(UserCreateRequest request) {
        if (userRepository.existsByEmail(request.email())) {
            throw new IllegalArgumentException("Email already exists");
        }

        if (request.age() < 18) {
            throw new IllegalArgumentException("User must be adult");
        }

        User user = userMapper.toEntity(request);
        User savedUser = userRepository.save(user);

        return userMapper.toResponse(savedUser);
    }
}

Controller

@RestController
@RequestMapping("/api/users")
public class UserController {

    private final UserService userService;

    public UserController(UserService userService) {
        this.userService = userService;
    }

    @PostMapping
    public UserResponse create(@RequestBody UserCreateRequest request) {
        return userService.create(request);
    }
}

13. Eng ko‘p qilinadigan xatolar

Xato 1: Controller’dan repository chaqirish

@RestController
public class UserController {

    private final UserRepository userRepository;

    @PostMapping("/users")
    public User create(@RequestBody User user) {
        return userRepository.save(user);
    }
}

To‘g‘risi:

Controller → Service → Repository

Xato 2: Entity’ni response qilib qaytarish

@GetMapping("/{id}")
public User getById(@PathVariable Long id) {
    return userRepository.findById(id).orElseThrow();
}

To‘g‘risi:

@GetMapping("/{id}")
public UserResponse getById(@PathVariable Long id) {
    return userService.getById(id);
}

Xato 3: Service ichida HTTP bilan ishlash

Yomon:

public ResponseEntity<UserResponse> create(UserCreateRequest request) {
    ...
}

Service ResponseEntity qaytarmagani yaxshi. ResponseEntity - web/controller tomonga yaqin narsa.

Yaxshiroq:

public UserResponse create(UserCreateRequest request) {
    ...
}

14. Qisqa qoida

Esda saqlash uchun:

Controller - HTTP bilan ishlaydi
Service - biznes logic bilan ishlaydi
Repository - database bilan ishlaydi
Entity - database modeli
DTO - API modeli
Mapper - DTO va Entity o‘rtasida aylantiradi

15. Javachi uchun vazifa

Bitta kichik loyiha yozing:

Product CRUD API

Kerakli endpointlar:

POST   /api/products
GET    /api/products
GET    /api/products/{id}
PUT    /api/products/{id}
DELETE /api/products/{id}

Struktura:

product
 ├── Product.java
 ├── ProductRepository.java
 ├── ProductService.java
 ├── ProductController.java
 ├── ProductCreateRequest.java
 ├── ProductUpdateRequest.java
 ├── ProductResponse.java
 └── ProductMapper.java

Product fieldlari:

id
name
price
quantity

Asosiy qoida:

Controller repository’ni chaqirmasin.
Entity response sifatida qaytmasin.
Business logic service ichida bo‘lsin.

Xulosa

Layered architecture - Spring Boot developer uchun eng muhim mavzulardan biri.

Bu arxitektura kodni tartibli qiladi:

Controller → Service → Repository → Database

DTO va Entity’ni ajratish esa xavfsizlik, tozalik va kelajakda kengaytirish uchun juda muhim.

1. Spring Data JPA nima?

Spring Data JPA - database bilan ishlashni osonlashtiradigan Spring moduli.

Oddiy qilib:

Java object  →  JPA/Hibernate  →  SQL  →  Database

Siz ko‘p hollarda SQL yozmaysiz. Spring Data JPA siz uchun query yaratadi.

Masalan:

public interface UserRepository extends JpaRepository<User, Long> {
}

Shu bitta interface orqali sizda avtomatik CRUD methodlar paydo bo‘ladi:

save()
findById()
findAll()
deleteById()
existsById()
count()

2. Entity va Repository eslatma

Entity

@Entity
@Table(name = "users")
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String fullName;

    private String email;

    private Integer age;

    // getters/setters
}

Bu users jadvaliga mos class.

Repository

public interface UserRepository extends JpaRepository<User, Long> {
}

Bu yerda:

JpaRepository<User, Long>

ma’nosi:

User - qaysi entity bilan ishlaydi
Long - entity id tipi

3. Built-in CRUD methodlar

Spring Data JPA sizga tayyor methodlar beradi.

Saqlash

User user = new User();
user.setFullName("Ali Valiyev");
user.setEmail("ali@mail.com");
user.setAge(22);

userRepository.save(user);

Agar id == null bo‘lsa - yangi record yaratadi.

Agar id mavjud bo‘lsa - update qiladi.

ID orqali topish

User user = userRepository.findById(1L)
        .orElseThrow(() -> new RuntimeException("User not found"));

findById() Optional<User> qaytaradi.

Yomon uslub:

User user = userRepository.findById(1L).get();

Nega yomon? Agar user topilmasa, NoSuchElementException chiqadi.

Yaxshiroq:

User user = userRepository.findById(1L)
        .orElseThrow(() -> new RuntimeException("User not found"));

Hammasini olish

List<User> users = userRepository.findAll();

Lekin katta jadvalda ehtiyot bo‘lish kerak. Agar jadvalda 1 million data bo‘lsa, findAll() hammasini RAM’ga olib keladi.

Real loyihada pagination ishlatiladi.

O‘chirish

userRepository.deleteById(1L);

Yoki:

userRepository.delete(user);

4. Derived Query Methods

Derived query - method nomiga qarab Spring o‘zi query yaratadi.

Masalan:

Optional<User> findByEmail(String email);

Spring buni taxminan shunday SQLga aylantiradi:

SELECT * FROM users WHERE email = ?

Eng ko‘p ishlatiladiganlari

public interface UserRepository extends JpaRepository<User, Long> {

    Optional<User> findByEmail(String email);

    List<User> findByAge(Integer age);

    List<User> findByAgeGreaterThan(Integer age);

    List<User> findByAgeLessThan(Integer age);

    boolean existsByEmail(String email);

    long countByAgeGreaterThan(Integer age);

    void deleteByEmail(String email);
}

And, Or

List<User> findByFullNameAndAge(String fullName, Integer age);

SQLga yaqin ma’nosi:

SELECT * FROM users
WHERE full_name = ? AND age = ?

Yana:

List<User> findByFullNameOrEmail(String fullName, String email);

Containing, StartsWith, EndsWith

List<User> findByFullNameContaining(String text);

Bu LIKE queryga o‘xshaydi:

WHERE full_name LIKE '%text%'

Misollar:

List<User> findByFullNameStartingWith(String prefix);

List<User> findByFullNameEndingWith(String suffix);

IgnoreCase

Optional<User> findByEmailIgnoreCase(String email);

Masalan:

ALI@MAIL.COM
ali@mail.com
Ali@Mail.Com

bularni bir xil deb qidirishi mumkin.

OrderBy

List<User> findByAgeGreaterThanOrderByFullNameAsc(Integer age);

Ma’nosi:

WHERE age > ?
ORDER BY full_name ASC

Yana:

List<User> findByAgeGreaterThanOrderByCreatedAtDesc(Integer age);

5. Derived query haddan oshsa yomonlashadi

Bu method o‘qilishi qiyin:

List<User> findByFullNameContainingAndAgeGreaterThanAndEmailEndingWithOrderByCreatedAtDesc(
        String name,
        Integer age,
        String emailDomain
);

Bunday holatda @Query ishlatgan yaxshi.

6. @Query nima?

@Query - query’ni o‘zingiz yozishingiz uchun ishlatiladi.

Ikki turi bor:

JPQL query
Native SQL query

7. JPQL query

JPQL database jadval nomi bilan emas, Entity nomi bilan ishlaydi.

Entity:

@Entity
public class User {
    private Long id;
    private String fullName;
    private String email;
    private Integer age;
}

Repository:

public interface UserRepository extends JpaRepository<User, Long> {

    @Query("select u from User u where u.age >= :age")
    List<User> findAdults(@Param("age") Integer age);
}

Bu yerda User - jadval emas, entity class nomi.

u.age - column emas, Java field nomi.

JPQL’da DTO qaytarish

Masalan response uchun faqat kerakli fieldlarni olish:

public record UserShortResponse(
        Long id,
        String fullName
) {
}

Repository:

@Query("""
       select new com.example.demo.user.UserShortResponse(u.id, u.fullName)
       from User u
       where u.age >= :age
       """)
List<UserShortResponse> findAdultUsers(@Param("age") Integer age);

Bu usul katta entity’ni to‘liq olib kelmaslik uchun foydali.

8. Native SQL query

Native query - to‘g‘ridan-to‘g‘ri SQL yozish.

@Query(value = "select * from users where age >= :age", nativeQuery = true)
List<User> findAdultsNative(@Param("age") Integer age);

Qachon kerak?

• murakkab SQL bo‘lsa

• database-specific function ishlatilsa

• performance uchun maxsus query yozish kerak bo‘lsa

• window function, CTE ishlatilsa

Lekin har doim native query yozish shart emas. Oddiy holatda derived query yoki JPQL yetadi.

9. Pagination nima?

Pagination - data’ni sahifalab olish.

Masalan hamma userlarni birdan olish yomon:

List<User> users = userRepository.findAll();

Agar 500 000 ta user bo‘lsa, server qiynaladi.

Shuning uchun:

1-sahifa: 20 ta user
2-sahifa: 20 ta user
3-sahifa: 20 ta user

Pageable bilan ishlash

Repository:

public interface UserRepository extends JpaRepository<User, Long> {

    Page<User> findByAgeGreaterThan(Integer age, Pageable pageable);
}

Service:

public Page<UserResponse> getUsers(int page, int size) {
    Pageable pageable = PageRequest.of(page, size, Sort.by("id").descending());

    return userRepository.findAll(pageable)
            .map(userMapper::toResponse);
}

Controller:

@GetMapping
public Page<UserResponse> getUsers(
        @RequestParam(defaultValue = "0") int page,
        @RequestParam(defaultValue = "20") int size
) {
    return userService.getUsers(page, size);
}

Request:

GET /api/users?page=0&size=20

10. Page, Slice, List farqi

Page

Page<User> users = userRepository.findAll(pageable);

Page qo‘shimcha ma’lumot beradi:

content
totalElements
totalPages
pageNumber
pageSize
first
last

Kamchiligi: ko‘pincha qo‘shimcha count query ishlaydi.

Slice

Slice<User> users = userRepository.findByAgeGreaterThan(18, pageable);

Slice faqat keyingi sahifa bor-yo‘qligini biladi:

content
hasNext
hasPrevious

totalElements va totalPages yo‘q.

Katta data uchun Slice ba’zan yengilroq bo‘ladi.

List

List<User> users = userRepository.findByAgeGreaterThan(18, pageable);

Faqat data qaytaradi. Pagination metadata yo‘q.

11. Sorting

Sorting - tartiblash.

Sort sort = Sort.by("fullName").ascending();
List<User> users = userRepository.findAll(sort);

Yoki:

Sort sort = Sort.by("createdAt").descending();

Pagination bilan:

Pageable pageable = PageRequest.of(
        0,
        20,
        Sort.by("createdAt").descending()
);

Ko‘p field bo‘yicha sorting:

Sort sort = Sort.by("age").descending()
        .and(Sort.by("fullName").ascending());

12. Entity relationshiplar

Real loyihada entitylar bir-biri bilan bog‘langan bo‘ladi.

Masalan:

User → Orders
Order → Product
Product → Category

JPA’da asosiy relationshiplar:

@OneToOne
@OneToMany
@ManyToOne
@ManyToMany

13. @ManyToOne

Eng ko‘p ishlatiladigan relationlardan biri.

Masalan:

Bitta userda ko‘p order bo‘lishi mumkin.
Bitta order faqat bitta userga tegishli.

Bu yerda Order → User munosabati ManyToOne.

@Entity
@Table(name = "orders")
public class Order {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private BigDecimal totalPrice;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "user_id")
    private User user;
}

Database’da:

orders
------
id
total_price
user_id

user_id - foreign key.

@JoinColumn

@JoinColumn(name = "user_id")
private User user;

Bu orders jadvalidagi user_id column users.id bilan bog‘lanishini bildiradi.

14. @OneToMany

User tomondan qarasak:

Bitta userda ko‘p order bor.

@Entity
@Table(name = "users")
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String fullName;

    @OneToMany(mappedBy = "user")
    private List<Order> orders = new ArrayList<>();
}

Bu yerda:

mappedBy = "user"

ma’nosi: relation egasi Order entity ichidagi user field.

Muhim qoida

Ko‘pincha @ManyToOne tomoni relation egasi bo‘ladi.

Ya’ni foreign key qaysi jadvalda bo‘lsa, relation egasi ham odatda o‘sha tomonda.

orders.user_id bor
demak relation egasi Order.user

15. @OneToOne

Masalan:

User - UserProfile
Bitta userda bitta profile bor.
Bitta profile bitta userga tegishli.

@Entity
public class UserProfile {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String bio;

    @OneToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "user_id")
    private User user;
}

Yoki User tomonda:

@OneToOne(mappedBy = "user")
private UserProfile profile;

16. @ManyToMany

Masalan:

Student ko‘p Course olishi mumkin.
Course’da ko‘p Student bo‘lishi mumkin.

@Entity
public class Student {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String fullName;

    @ManyToMany
    @JoinTable(
            name = "student_courses",
            joinColumns = @JoinColumn(name = "student_id"),
            inverseJoinColumns = @JoinColumn(name = "course_id")
    )
    private List<Course> courses = new ArrayList<>();
}

@Entity
public class Course {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String title;
}

Database’da oraliq jadval bo‘ladi:

student_courses
---------------
student_id
course_id

Real loyihada @ManyToManydan ehtiyot bo‘ling

Ko‘p real holatda @ManyToMany o‘rniga alohida entity ishlatgan yaxshi.

Masalan:

StudentCourse

Nega?

Chunki oraliq jadvalda qo‘shimcha fieldlar bo‘lishi mumkin:

student_id
course_id
joined_at
status
grade

Shunda bunday yoziladi:

@Entity
public class StudentCourse {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @ManyToOne(fetch = FetchType.LAZY)
    private Student student;

    @ManyToOne(fetch = FetchType.LAZY)
    private Course course;

    private LocalDateTime joinedAt;

    private String status;
}

Bu usul real loyihada ancha nazoratli.

17. FetchType.LAZY va FetchType.EAGER

Bu juda muhim.

LAZY

LAZY - bog‘langan entity kerak bo‘lganda yuklanadi.

@ManyToOne(fetch = FetchType.LAZY)
private User user;

Masalan orderni oldingiz:

Order order = orderRepository.findById(1L).orElseThrow();

Bu paytda user hali yuklanmagan bo‘lishi mumkin.

Agar keyin chaqirsangiz:

order.getUser().getFullName();

shunda user yuklanadi.

EAGER

EAGER - bog‘langan entity darhol yuklanadi.

@ManyToOne(fetch = FetchType.EAGER)
private User user;

Orderni olsangiz, user ham birga keladi.

Bu qulay ko‘rinadi, lekin katta loyihada performance muammo keltiradi.

Amaliy maslahat

Ko‘pincha shunday ishlatiladi:

@ManyToOne(fetch = FetchType.LAZY)
@OneToOne(fetch = FetchType.LAZY)
@OneToMany(fetch = FetchType.LAZY)
@ManyToMany(fetch = FetchType.LAZY)

Ya’ni defaultga ishonib ketmasdan, LAZYni aniq yozish yaxshi.

18. N+1 problem

Bu JPA’da eng mashhur performance muammolardan biri.

Tasavvur qiling:

List<Order> orders = orderRepository.findAll();

for (Order order : orders) {
    System.out.println(order.getUser().getFullName());
}

Agar 100 ta order bo‘lsa:

1 ta query - orders olish uchun
100 ta query - har bir order userini olish uchun

Jami:

101 query

Bu N+1 problem deyiladi.

Yechim: fetch join

@Query("""
       select o from Order o
       join fetch o.user
       """)
List<Order> findAllWithUser();

Bu order va userni bitta query bilan olib keladi.

Yechim: EntityGraph

@EntityGraph(attributePaths = "user")
List<Order> findAll();

Bu ham userni oldindan yuklab beradi.

19. CascadeType

Cascade - bir entityga qilingan amal bog‘langan entityga ham ta’sir qilish-qilmasligini belgilaydi.

Masalan:

@OneToMany(mappedBy = "user", cascade = CascadeType.ALL)
private List<Order> orders = new ArrayList<>();

Agar user saqlansa, orderlar ham saqlanishi mumkin.

Agar user o‘chirilsa, orderlar ham o‘chishi mumkin.

Cascade turlari

PERSIST  - save qilganda bog‘langan entity ham save bo‘ladi
MERGE    - update qilganda bog‘langan entity ham update bo‘ladi
REMOVE   - delete qilganda bog‘langan entity ham delete bo‘ladi
REFRESH  - refresh amalini uzatadi
DETACH   - detach amalini uzatadi
ALL      - hammasi

Xavfli joyi

@ManyToOne(cascade = CascadeType.ALL)
private User user;

Bu xavfli bo‘lishi mumkin.

Masalan orderni o‘chirganda user ham o‘chib ketishi mumkin.

Amaliy qoida:

@ManyToOne tomonda CascadeType.ALL ishlatishga shoshilmang.

CascadeType.REMOVEni ham ehtiyot ishlating.

20. orphanRemoval

orphanRemoval = true - parentdan olib tashlangan child database’dan ham o‘chadi.

@OneToMany(
        mappedBy = "user",
        cascade = CascadeType.ALL,
        orphanRemoval = true
)
private List<Order> orders = new ArrayList<>();

Masalan:

user.getOrders().remove(order);

Shunda order database’dan ham o‘chishi mumkin.

Bu kuchli feature, lekin ehtiyot ishlatish kerak.

21. Transaction bilan relationlar

Relationlar bilan ishlaganda @Transactional muhim.

Masalan:

@Transactional
public OrderResponse createOrder(Long userId, CreateOrderRequest request) {
    User user = userRepository.findById(userId)
            .orElseThrow(() -> new RuntimeException("User not found"));

    Order order = new Order();
    order.setUser(user);
    order.setTotalPrice(request.totalPrice());

    Order savedOrder = orderRepository.save(order);

    return orderMapper.toResponse(savedOrder);
}

Nega service’da @Transactional yaxshi?

Chunki bitta business operation ichida:

Userni topish
Order yaratish
Orderni saqlash
Response tayyorlash

hammasi bir transaction doirasida bo‘ladi.

22. Update qilishda ehtiyot bo‘lish

Yomonroq usul:

public User update(Long id, User request) {
    request.setId(id);
    return userRepository.save(request);
}

Bu xavfli. Chunki request ichida kelmagan fieldlar null bo‘lib qolishi mumkin.

Yaxshiroq:

@Transactional
public UserResponse update(Long id, UserUpdateRequest request) {
    User user = userRepository.findById(id)
            .orElseThrow(() -> new RuntimeException("User not found"));

    user.setFullName(request.fullName());
    user.setAge(request.age());

    return userMapper.toResponse(user);
}

Bu yerda save() chaqirmasangiz ham bo‘ladi, chunki entity transaction ichida managed holatda. Hibernate o‘zgarishni kuzatadi va transaction oxirida update qiladi.

Bu dirty checking deyiladi.

23. Dirty Checking nima?

Dirty checking - Hibernate entitydagi o‘zgarishlarni avtomatik aniqlashi.

@Transactional
public void changeEmail(Long userId, String newEmail) {
    User user = userRepository.findById(userId)
            .orElseThrow();

    user.setEmail(newEmail);
}

Bu yerda save() yo‘q.

Lekin transaction tugaganda Hibernate taxminan shunday SQL bajaradi:

UPDATE users SET email = ? WHERE id = ?

Bu faqat entity managed holatda va transaction ichida bo‘lsa ishlaydi.

24. DTO projection

Ba’zan entityni to‘liq olish kerak emas.

Masalan faqat:

id
fullName
email

kerak.

Interface projection:

public interface UserView {
    Long getId();
    String getFullName();
    String getEmail();
}

Repository:

List<UserView> findByAgeGreaterThan(Integer age);

Bu response uchun yengilroq bo‘lishi mumkin.

25. Amaliy Product + Category misol

Category entity

@Entity
@Table(name = "categories")
public class Category {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;
}

Product entity

@Entity
@Table(name = "products")
public class Product {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;

    private BigDecimal price;

    private Integer quantity;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "category_id")
    private Category category;
}

ProductRepository

public interface ProductRepository extends JpaRepository<Product, Long> {

    List<Product> findByNameContainingIgnoreCase(String name);

    Page<Product> findByCategoryId(Long categoryId, Pageable pageable);

    boolean existsByName(String name);

    @Query("""
           select p from Product p
           join fetch p.category
           where p.id = :id
           """)
    Optional<Product> findByIdWithCategory(@Param("id") Long id);
}

ProductResponse

public record ProductResponse(
        Long id,
        String name,
        BigDecimal price,
        Integer quantity,
        Long categoryId,
        String categoryName
) {
}

Mapper

@Component
public class ProductMapper {

    public ProductResponse toResponse(Product product) {
        Category category = product.getCategory();

        return new ProductResponse(
                product.getId(),
                product.getName(),
                product.getPrice(),
                product.getQuantity(),
                category != null ? category.getId() : null,
                category != null ? category.getName() : null
        );
    }
}

26. Javachi uchun eng muhim qoidalar

Repository’da

Repository faqat database bilan ishlasin:

public interface ProductRepository extends JpaRepository<Product, Long> {
}

Business logic yozmang.

Service’da

Service business operationni boshqarsin:

@Transactional
public ProductResponse create(ProductCreateRequest request) {
    // validate
    // find category
    // create product
    // save
    // return response
}

Controller’da

Controller faqat request/response bilan ishlasin:

@PostMapping
public ProductResponse create(@RequestBody ProductCreateRequest request) {
    return productService.create(request);
}

27. Ko‘p uchraydigan xatolar

Xato 1: findAll()ni doim ishlatish

List<Product> products = productRepository.findAll();

Katta jadvalda yomon.

Yaxshiroq:

Page<Product> products = productRepository.findAll(pageable);

Xato 2: Entity’ni API response qilish

@GetMapping
public List<Product> getAll() {
    return productRepository.findAll();
}

Yaxshiroq:

@GetMapping
public Page<ProductResponse> getAll(...) {
    return productService.getAll(...);
}

Xato 3: EAGERni ko‘p ishlatish