Arxitektura uslublari (Architecture Styles)

Arxitektor darajasida endi savol "kod qanday yoziladi?" emas, balki:

"Butun sistema qanday quriladi, qanday o‘sadi, qanday buzilmaydi va 2-5 yildan keyin ham qanday yashaydi?"

Bu mavzu quyidagilarni o‘z ichiga oladi: Monolith vs modular monolith vs microservices, Hexagonal Architecture, Clean/Onion Architecture, Event Sourcing & CQRS, DDD, Cell-based architecture.

1. Architecture style nima?

Architecture style - bu sistemani katta darajada qanday tashkil qilish usuli.

Masalan:

Frontend
   |
Backend
   |
Database

Bu oddiy ko‘rinadi. Lekin backend ichida savollar ko‘p:

• Hammasi bitta app bo‘ladimi?

• Har bir modul alohida servis bo‘ladimi?

• Biznes logika controller ichidami yoki domain ichidami?

• Database bitta bo‘ladimi yoki har servisniki alohidami?

• Event bilan ishlaymizmi yoki oddiy REST API bilanmi?

• System buzilsa, qaysi qismi ishlashda davom etadi?

Arxitektor shu savollarga javob beradigan odam.

2. Monolith Architecture

Monolith nima?

Monolith - butun backend bitta katta application ichida bo‘ladi.

Masalan:

E-commerce App
 ├── User module
 ├── Product module
 ├── Order module
 ├── Payment module
 ├── Delivery module
 └── Admin module

Hammasi bitta Spring Boot project ichida.

Frontend → Spring Boot Monolith → PostgreSQL

Real misol

Online do‘kon qilaylik:

• user ro‘yxatdan o‘tadi

• product ko‘radi

• savatga qo‘shadi

• order qiladi

• payment qiladi

Bularning hammasi bitta backend ichida bo‘lsa - bu monolith.

Afzalliklari

Monolith yomon emas. Ayniqsa boshida juda foydali.

Kamchiliklari

Loyiha kattalashganda muammo chiqadi.

Qachon monolith tanlanadi?

Monolith tanlash kerak, agar:

• loyiha yangi bo‘lsa;

• biznes hali to‘liq aniq bo‘lmasa;

• team kichik bo‘lsa;

• traffic hali katta bo‘lmasa;

• tez MVP chiqarish kerak bo‘lsa.

Arxitektor xulosasi:

Ko‘p hollarda loyiha microservices bilan emas, yaxshi yozilgan monolith bilan boshlanishi kerak.

3. Modular Monolith

Modular monolith nima?

Modular monolith - bitta application, lekin ichida modullar aniq chegaralangan.

Spring Boot App
 ├── user
 │    ├── api
 │    ├── domain
 │    ├── application
 │    └── infrastructure
 │
 ├── order
 │    ├── api
 │    ├── domain
 │    ├── application
 │    └── infrastructure
 │
 └── payment
      ├── api
      ├── domain
      ├── application
      └── infrastructure

Bu hali ham bitta deploy qilinadi:

Frontend → Modular Monolith → Database

Lekin ichki tartib kuchliroq.

Oddiy monolithdan farqi

Oddiy monolithda:

orderService.createOrder();
productRepository.updateStock();
paymentRepository.save();

Har kim har kimni chaqirib ketadi.

Modular monolithda esa:

Order module → Product module bilan faqat public interface orqali gaplashadi
Order module → Product ichki repositorysiga kira olmaydi

Java/Spring Boot’da modular monolith misoli

com.example.shop
 ├── user
 │    ├── UserFacade.java
 │    ├── UserService.java
 │    └── UserRepository.java
 │
 ├── order
 │    ├── OrderFacade.java
 │    ├── OrderService.java
 │    └── OrderRepository.java
 │
 └── payment
      ├── PaymentFacade.java
      ├── PaymentService.java
      └── PaymentRepository.java

Order module payment’ga to‘g‘ridan-to‘g‘ri repository orqali kirmaydi.

Yaxshiroq variant:

public interface PaymentPort {
    PaymentResult pay(PaymentCommand command);
}

Order faqat PaymentPort orqali ishlaydi.

Afzalliklari

Kamchiliklari

Qachon modular monolith tanlanadi?

Eng yaxshi tanlovlardan biri:

• loyiha o‘sishi kutilsa;

• microservicesga hali erta bo‘lsa;

• domain murakkab bo‘lsa;

• team o‘rtacha bo‘lsa;

• kelajakda ayrim modullarni alohida servis qilish ehtimoli bo‘lsa.

Arxitektor xulosasi:

Ko‘p real biznes sistemalar uchun eng sog‘lom start - modular monolith.

4. Microservices Architecture

Microservices nima?

Microservices - sistema bir nechta mustaqil servisga bo‘linadi.

Frontend
   |
API Gateway
   |
 ├── User Service       → user_db
 ├── Product Service    → product_db
 ├── Order Service      → order_db
 ├── Payment Service    → payment_db
 └── Notification Service → notification_db

Har servis:

• alohida deploy qilinadi;

• o‘z database’iga ega bo‘lishi mumkin;

• alohida team tomonidan boshqarilishi mumkin;

• REST, gRPC yoki message broker orqali gaplashadi.

Microservices nimani hal qiladi?

Masalan payment juda ko‘p ishlatiladi.

Monolithda:

Butun app scale qilinadi

Microservicesda:

Faqat Payment Service scale qilinadi

Yoki notification service yiqilsa, order service ishlashda davom etishi mumkin.

Afzalliklari

Kamchiliklari

Microservices - bu "zamonaviy" ko‘ringani bilan juda qimmat architecture.

Eng katta xato

Ko‘p teamlar shunday qiladi:

"Biz professional ko‘rinish uchun boshidan microservices qilamiz."

Bu xavfli.

Agar teamda quyidagilar bo‘lmasa, microservices og‘riq beradi:

• kuchli DevOps;

• monitoring;

• distributed tracing;

• message broker tajribasi;

• service ownership;

• yaxshi test strategy;

• domain chegaralari aniq bo‘lishi.

Qachon microservices tanlanadi?

Microservices kerak bo‘ladi, agar:

• sistema katta bo‘lsa;

• teamlar ko‘p bo‘lsa;

• modullar mustaqil rivojlansa;

• har modulning scaling talabi boshqacha bo‘lsa;

• deployment tez-tez va mustaqil bo‘lishi kerak bo‘lsa;

• domain chegaralari aniq bo‘lsa.

Arxitektor xulosasi:

Microservices - kodni bo‘lish emas. Bu ownership, deployment, monitoring, data consistency va organization architecture masalasi.

5. Hexagonal Architecture

Hexagonal Architecture nima?

Hexagonal Architecture yana Ports & Adapters deb ham ataladi.

Asosiy g‘oya:

Biznes logika framework, database, HTTP, Kafka, Redis kabi tashqi narsalarga qaram bo‘lmasligi kerak.

Ya’ni domain markazda turadi.

          REST Controller
                |
             Adapter
                |
Input Port → Application Service → Output Port
                |
             Adapter
                |
          Database / Kafka / External API

Oddiy yomon struktura

@RestController
public class OrderController {

    @Autowired
    private OrderRepository orderRepository;

    @PostMapping("/orders")
    public void create(@RequestBody OrderRequest request) {
        Order order = new Order();
        orderRepository.save(order);
    }
}

Bu yerda controller, business logic va database aralashib ketgan.

Hexagonal usul

Domain

public class Order {
    private OrderId id;
    private Money total;

    public void confirm() {
        // business rule
    }
}

Input port

public interface CreateOrderUseCase {
    OrderId create(CreateOrderCommand command);
}

Application service

public class CreateOrderService implements CreateOrderUseCase {

    private final OrderRepositoryPort orderRepository;

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

    public OrderId create(CreateOrderCommand command) {
        Order order = Order.create(command.items());
        orderRepository.save(order);
        return order.getId();
    }
}

Output port

public interface OrderRepositoryPort {
    void save(Order order);
}

Adapter

@Repository
public class JpaOrderRepositoryAdapter implements OrderRepositoryPort {

    private final SpringDataOrderRepository repository;

    public void save(Order order) {
        repository.save(OrderEntity.from(order));
    }
}

Nima foyda?

Qachon ishlatiladi?

Hexagonal yaxshi tanlov:

• domain murakkab bo‘lsa;

• testability muhim bo‘lsa;

• external systemlar ko‘p bo‘lsa;

• business logic uzoq yashashi kerak bo‘lsa;

• frameworkga qattiq bog‘lanib qolmaslik kerak bo‘lsa.

Arxitektor xulosasi:

Hexagonal Architecture’da Spring Boot asosiy qahramon emas. Asosiy qahramon - business logic.

6. Clean Architecture / Onion Architecture

Clean Architecture nima?

Clean Architecture ham Hexagonalga o‘xshaydi. Asosiy prinsip:

Dependency har doim ichkariga qaraydi.

[ Frameworks & Drivers ]
        ↓
[ Interface Adapters ]
        ↓
[ Use Cases ]
        ↓
[ Entities / Domain ]

Eng ichkarida domain turadi. Eng tashqarida frameworklar turadi.

Onion Architecture

Onion Architecture ham qatlamli:

Infrastructure
   Application
      Domain

Domain markazda.

Tashqi qatlamlar ichki qatlamlarga bog‘liq bo‘ladi, lekin ichki qatlam tashqini bilmaydi.

Layered Architecture’dan farqi

Classic layered architecture:

Controller → Service → Repository → Database

Bu oddiy loyihalarda yaxshi.

Lekin Clean Architecture’da:

Controller → UseCase → Port → Adapter → Database

Repository interface ichkarida bo‘ladi, implementation tashqarida.

Qachon Clean Architecture kerak?

Kerak bo‘ladi:

• enterprise system;

• business rules murakkab;

• uzoq muddat yashaydigan loyiha;

• testlar muhim;

• frameworklardan mustaqillik kerak;

• domain alohida qiymatga ega.

Kerak bo‘lmasligi mumkin:

• oddiy CRUD admin panel;

• kichik MVP;

• 2-3 endpointli servis;

• vaqt juda qisqa bo‘lsa.

Arxitektor xulosasi:

Clean Architecture hamma joyga majburiy emas. Lekin murakkab domain bo‘lsa, kodni uzoq umrli qiladi.

7. CQRS

CQRS nima?

CQRS - Command Query Responsibility Segregation.

Ya’ni:

• yozish operatsiyalari alohida;

• o‘qish operatsiyalari alohida.

Command side → create/update/delete
Query side   → read/search/report

Oddiy CRUD’da bitta model ham yozadi, ham o‘qiydi.

CQRS’da esa:

Write Model: Order, Payment, Invoice
Read Model: OrderView, DashboardView, ReportView

Oddiy misol

Order yaratish:

POST /orders

Bu command.

Order ro‘yxatini ko‘rish:

GET /orders?status=PAID

Bu query.

CQRS’da ularning modeli alohida bo‘lishi mumkin.

Qachon foydali?

CQRS foydali, agar:

• o‘qish va yozish talablari juda farq qilsa;

• report/dashboard og‘ir bo‘lsa;

• read model denormalized bo‘lsa;

• high traffic read endpointlar bo‘lsa;

• event-driven system bo‘lsa.

Kamchiligi

Arxitektor xulosasi:

CQRS’ni oddiy CRUD uchun ishlatish ortiqcha. Lekin katta read/write farqi bo‘lsa, kuchli yechim.

8. Event Sourcing

Event Sourcing nima?

Oddiy sistemada biz hozirgi holatni saqlaymiz:

Order status = PAID

Event Sourcing’da esa holat emas, voqealar saqlanadi:

OrderCreated
PaymentReceived
OrderPaid
OrderShipped

Hozirgi holat shu eventlardan tiklanadi.

Misol

Oddiy database:

Event sourcing:

Bu orqali tarix to‘liq saqlanadi.

Afzalliklari

Kamchiliklari

Qachon ishlatiladi?

Event Sourcing mos:

• banking;

• payment;

• audit muhim systemlar;

• order lifecycle murakkab bo‘lgan joylar;

• rollback/replay kerak bo‘lgan systemlar;

• business eventlar juda muhim bo‘lgan domainlar.

Mos emas:

• oddiy CRUD;

• admin panel;

• kichik loyiha;

• team event-driven tajribasiz bo‘lsa.

Arxitektor xulosasi:

Event Sourcing - database tanlovi emas, butun fikrlash modelini o‘zgartiradigan architecture style.

9. Domain-Driven Design - DDD

DDD nima?

DDD - Domain-Driven Design.

Asosiy fikr:

Software business domain atrofida qurilishi kerak, database yoki framework atrofida emas.

Masalan banking system’da asosiy tushunchalar:

• Account

• Transaction

• Balance

• Limit

• Transfer

• Fraud Check

E-commerce’da:

• Product

• Cart

• Order

• Payment

• Delivery

• Refund

DDD shu tushunchalarni to‘g‘ri model qilishga yordam beradi.

Bounded Context

Bounded Context - bitta so‘z turli joyda turli ma’noga ega bo‘lishi mumkinligini tan olish.

Masalan Customer:

Sales context:
Customer = lead, potential buyer

Billing context:
Customer = payer with billing details

Support context:
Customer = ticket owner

Bitta Customer class qilib hammasiga ishlatish xato bo‘lishi mumkin.

Aggregate

Aggregate - birgalikda consistency saqlashi kerak bo‘lgan obyektlar guruhi.

Masalan:

Order
 ├── OrderItem
 ├── ShippingAddress
 └── PaymentStatus

Bu yerda Order aggregate root bo‘lishi mumkin.

Tashqaridan OrderItemni to‘g‘ridan-to‘g‘ri o‘zgartirmaysiz. Faqat Order orqali:

order.addItem(productId, quantity);
order.confirm();
order.cancel();

DDD qachon kerak?

DDD kerak:

• domain murakkab bo‘lsa;

• business rules ko‘p bo‘lsa;

• terminlar chalkash bo‘lsa;

• bir nechta department/tizim bo‘lsa;

• microservices chegarasini aniqlash kerak bo‘lsa.

DDD shart emas:

• oddiy CRUD;

• faqat data entry app;

• kichik admin panel;

• biznes logika deyarli yo‘q bo‘lsa.

Arxitektor xulosasi:

DDD class nomlarini chiroyli qilish emas. Bu biznesni to‘g‘ri tushunib, system chegaralarini to‘g‘ri chizish.

10. Cell-Based Architecture

Cell-based architecture nima?

Cell-based architecture - sistemani mustaqil "cell"larga bo‘lish.

Har bir cell o‘z ichida kerakli qismlarga ega bo‘ladi:

Cell A
 ├── API
 ├── Services
 ├── Database
 └── Cache

Cell B
 ├── API
 ├── Services
 ├── Database
 └── Cache

Traffic celllarga bo‘linadi.

Masalan:

Users 1-100000     → Cell A
Users 100001-200000 → Cell B
Users 200001-300000 → Cell C

Nima uchun kerak?

Katta sistemalarda bitta global failure butun sistemani yiqitmasligi kerak.

Agar Cell B’da muammo bo‘lsa:

Cell A ishlayveradi
Cell C ishlayveradi
Faqat Cell B foydalanuvchilari ta’sirlanadi

Bu blast radius’ni kamaytiradi.

Qachon kerak?

Cell-based architecture odatda juda katta scale’da kerak bo‘ladi:

• millionlab userlar;

• multi-region architecture;

• SaaS platformalar;

• tenant isolation kerak bo‘lsa;

• failure isolation juda muhim bo‘lsa.

Oddiy loyihalar uchun bu ortiqcha.

Arxitektor xulosasi:

Cell-based architecture - katta scale va reliability uchun. Kichik projectda bu overengineering.

11. Qaysi architecture style’ni qachon tanlash kerak?

12. Arxitektor uchun eng muhim fikr

Arxitektor hech qachon "eng zo‘r architecture"ni tanlamaydi.

U quyidagini tanlaydi:

Hozirgi biznesga mos
Team ko‘tara oladigan
Kelajakda o‘sishga tayyor
Monitoring va deployment bilan boshqariladigan
Eng kam keraksiz complexity beradigan architecture

13. Amaliy tavsiya - Java/Spring loyihalar uchun

Ko‘p real Spring Boot loyihalar uchun yaxshi start:

Modular Monolith
+ Clean/Hexagonal Architecture elementlari
+ DDD bounded context fikrlashi
+ Keyinchalik kerak bo‘lsa microservicesga ajratish

Masalan:

shop-app
 ├── user
 ├── catalog
 ├── order
 ├── payment
 ├── notification
 └── shared-kernel

Boshida bitta deploy.

Keyin payment juda katta bo‘lib ketsa:

payment module → Payment Service

Shunda microservicesga o‘tish tabiiy bo‘ladi, majburiy emas.

Yakuniy formula

Junior kod yozadi.
Middle production kod yozadi.
Senior subsystem egasi bo‘ladi.
Arxitektor esa butun system qanday yashashini loyihalaydi.

Architecture styles mavzusida eng muhim dars:

Microservices har doim yaxshi emas. Monolith har doim yomon emas. To‘g‘ri architecture - contextga mos architecture.