9.7-bob: Event-driven architecture, CQRS, Event Sourcing

  EDA — komponentlar EVENT (voqea) orqali gaplashadi:
  Event = "nimadir sodir bo'ldi" (o'tgan zamon — OrderCreated, PaymentReceived)

  An'anaviy (komanda — to'g'ridan):
  OrderService  EmailService.send() (to'g'ridan chaqiradi — qattiq bog'liq)

  Event-driven (voqea — bo'shashgan):
  OrderService  emit("OrderCreated")  [EVENT BUS]
                                          ├ EmailService (tinglaydi)
                                          ├ SmsService (tinglaydi)
                                          └ Analytics (tinglaydi)
   OrderService tinglovchilarni BILMAYDI (mustaqil qo'shiladi)

  EVENT TURLARI:
  - Domain event 9.4-bob: biznes voqea (OrderCreated — domen ichida)
  - Integration event: xizmatlararo (mikroservis — Kafka/RabbitMQ — 9.6)

  EVENT BUS (event'larni tarqatuvchi):
  - In-process: EventEmitter 8.16-bob, NestJS @OnEvent (monolit — 9.5)
  - Distributed: Kafka, RabbitMQ (mikroservis — 9.6)

  EVENT vs COMMAND:
  - Command: "buni qil" (DoSomething — bitta qabul qiluvchi, javob)
  - Event: "bu bo'ldi" (SomethingHappened — ko'p tinglovchi, javobsiz)

  AFZALLIK:
   Bo'shashgan bog'lanish (mustaqil — OCP — 9.1)
   Kengaytiriladigan (yangi tinglovchi — eski o'zgarmaydi)
   Chidamli (asinxron — tinglovchi yiqilsa, event navbatda — 9.6)
   Masshtab (parallel tinglovchilar)

  KAMCHILIK:
   Murakkab kuzatuv (oqim ko'rinmaydi — qaysi event qayerga?)
   Eventual consistency (darrov emas — 2.7)
   Debug qiyin (asinxron — stack trace yo'q)
   Event tartibi (kafolat qiyin — distributed)

   Bo'shashgan, kengaytiriladigan, lekin kuzatuvi murakkab

  CQRS — o'qish (Query) va yozish (Command) ni AJRATISH:

  An'anaviy (bir model — CRUD):
  Bir Model  o'qish ham, yozish ham (bir DB, bir struktura)

  CQRS (ikki model):
  COMMAND (yozish)  Write Model  Write DB (normalized, qoidalar — 6.9)
  QUERY (o'qish)    Read Model   Read DB (denormalized, tez — optimallashgan)

  Nega:
  - O'qish va yozish YUKI har xil (o'qish 100x ko'p — alohida masshtab)
  - O'qish va yozish MODELI har xil (yozish — qoida; o'qish — tez ko'rsatish)

  CQRS OQIMI:
  1. Command (yozish): "BuyurtmaYarat"  Command Handler  Write DB
      biznes qoidalar, validatsiya, tranzaksiya 6.9-bob
  2. Event: yozishdan keyin event ("OrderCreated")
  3. Projection: event  Read Model yangilanadi (denormalized)
      Read DB: tayyor ko'rinish (JOIN'siz, tez o'qish)
  4. Query (o'qish): Read DB'dan to'g'ridan (tez — hisoblanmagan)

   Read model — EVENTUAL (yozishdan biroz keyin yangilanadi — 2.7)
   Read DB boshqa bo'lishi mumkin (PostgreSQL yozish, Elasticsearch o'qish)

  EVENT SOURCING — holatni emas, EVENT'larni saqlash:

  An'anaviy (state-oriented): joriy holat saqlanadi
  account: { balans: 500000 }   har o'zgarishda ustiga yoziladi (tarix yo'q)

  Event Sourcing: barcha event saqlanadi (event store)
  events: [
    { MoneyDeposited: 1000000 },    har event o'zgarmas (immutable)
    { MoneyWithdrawn: 300000 },
    { MoneyWithdrawn: 200000 },
  ]
   joriy holat = event'lar YIG'INDISI (replay): 1M - 300k - 200k = 500k

   To'liq tarix (audit — 8.26 tabiiy); "qaytarib o'ynash" (replay)
   Vaqt sayohati (har qanday o'tmish holatni tiklash)
   Murakkab (event store, snapshot, replay)

  EVENTUAL CONSISTENCY — ma'lumot DARROV emas, BIROZ KEYIN izchil:

  Strong consistency (ACID — monolit): yozish  darrov o'qishda ko'rinadi
  Eventual consistency (CQRS/distributed): yozish  read model BIROZ KEYIN

  Misol: buyurtma yaratildi (write)  read model 100ms keyin yangilanadi
   shu 100ms ichida o'qisa, eski ma'lumot (stale)

  YECHIMLAR:
  - Optimistik UI (frontend darrov ko'rsatadi, keyin moslaydi)
  - Versiya/correlation ID (yozish versiyasini kuting)
  - "Yaratildi" javobida ma'lumotni qaytarish (read'siz)

   Biznes eventual'ga TOQAT qilsa — CQRS; aks holda — monolit (ACID)

  MUAMMO: DB'ga yozish + event yuborish — atomik emas!
  - DB'ga saqladi  event yuborishdan oldin yiqildi  event YO'QOLDI
  - yoki event yubordi  DB saqlanmadi  nomutanosib

  OUTBOX PATTERN (ishonchli):
  1. Bir TRANZAKSIYADA: biznes ma'lumot + event "outbox" jadvaliga (6.9 ACID)
  2. Alohida jarayon outbox'ni o'qib, event'ni queue'ga yuboradi
  3. Yuborilgach — outbox'da belgilaydi

   DB va event ATOMIK (ikkalasi yoki hech narsa — yo'qolmaydi)
   "Dual write" muammosi yechimi (DB + queue ikki alohida tizim)

  KO'PINCHA BIRGA ISHLATILADI (lekin alohida ham):

  Event Sourcing (event store)  event'lar manba
         │
         ├ CQRS Write: command  event  event store
         │
         ├ Event'lar  Projection  Read Model (CQRS Query — 2.5)
         │
         └ Event'lar  EDA (boshqa xizmatlar tinglaydi — 2.1)

   Event Sourcing event'larni yaratadi; CQRS o'qish/yozish ajratadi;
    EDA event'larni tarqatadi (uch naqsh — bitta event oqimi atrofida)

   Alohida ham: faqat EDA (event), faqat CQRS (read/write) — mustaqil

  QACHON KERAK:
   EDA: bo'shashgan bog'lanish, ko'p reaksiya (notification, integratsiya)
   CQRS: o'qish/yozish yuki yoki modeli juda farq (murakkab o'qish)
   Event Sourcing: to'liq audit, "nima bo'lgan", vaqt sayohati (bank, moliyaviy)

  QACHON EMAS (over-engineering — 9.1: 2.12):
   Oddiy CRUD (ma'lumot saqlash/o'qish)
   Kichik loyiha; strong consistency majburiy (eventual toqat qilmaydi)
   Jamoa tajribasiz (murakkablik — debug/kuzatuv qiyin)

   EDA — nisbatan oson (boshlash mumkin); CQRS/ES — murakkab (ehtiyot)

// NestJS @nestjs/cqrs — Command/Query/Event ajratish
// Command (yozish)
export class CreateOrderCommand { constructor(public dto: any) {} }

@CommandHandler(CreateOrderCommand)
export class CreateOrderHandler implements ICommandHandler<CreateOrderCommand> {
  async execute(command: CreateOrderCommand) {
    const order = await this.repo.save(command.dto);    // write model
    this.eventBus.publish(new OrderCreatedEvent(order.id));   // event (2.2)
  }
}

// Query (o'qish)
@QueryHandler(GetOrdersQuery)
export class GetOrdersHandler implements IQueryHandler<GetOrdersQuery> {
  async execute() { return this.readRepo.find(); }      // read model (tez)
}

// Event handler (projection / EDA)
@EventsHandler(OrderCreatedEvent)
export class OrderCreatedHandler implements IEventHandler<OrderCreatedEvent> {
  async handle(event: OrderCreatedEvent) {
    await this.readModel.yangila(event.orderId);         // projection (read model)
  }
}

  "Event-driven" — bitta so'z, LEKIN uch xil uslub (Martin Fowler tasnifi).
  Farqni bilmaslik — arxitektura chalkashligining asosiy sababi:

  1) EVENT NOTIFICATION (voqea bildirishnomasi):
     Event — faqat "signal": { type: "OrderCreated", orderId: "42" }
     Tinglovchi kerakli ma'lumotni O'ZI so'raydi (API call: GET /orders/42)
      Yengil event (kichik), producer/consumer bo'shashgan
      Ko'p qayta so'rov (chatty), consumer producer'ga bog'liq (so'rash uchun)

  2) EVENT-CARRIED STATE TRANSFER (holat tashuvchi event):
     Event — to'liq ma'lumot: { type: "OrderCreated", order: { id, items, summa, ... } }
     Tinglovchi qo'shimcha so'rov QILMAYDI (hammasi event ichida)
      Consumer mustaqil (producer'ga so'ramaydi), so'rov kam, chidamli
      Katta event, ma'lumot dublikat (har consumer nusxa saqlaydi), eskirish xavfi

  3) EVENT SOURCING 2.6-bob:
     Event — HOLAT MANBASI: barcha event saqlanadi  holat = replay
      To'liq tarix, audit, vaqt sayohati
      Eng murakkab (event store, versioning, snapshot)

   1 va 2 — muvozanat: signal yengil, lekin chatty; state transfer og'ir,
    lekin mustaqil. Ko'p tizim ikkalasini aralashtiradi (muhim event — state,
    boshqasi — notification).

  Ikkalasi ham "event", LEKIN chegara va shartnoma har xil:

  DOMAIN EVENT 9.4-bob:
  - Chegara: BITTA bounded context / service ICHIDA
  - Shakl: boy domen obyekti (Value Object, Entity ID)
  - Shartnoma: ichki (o'zgartirish oson — bir jamoa)
  - Misol: OrderPlaced (Order aggregate ichida — 9.5)
  - Uzatuv: in-process (EventEmitter, @nestjs/cqrs EventBus)

  INTEGRATION EVENT:
  - Chegara: service'lar ORASIDA (tashqi — Kafka/RabbitMQ 9.6)
  - Shakl: TEKIS, primitiv (id, string, number — versiyalanadigan shartnoma)
  - Shartnoma: PUBLIK (o'zgartirish qiyin — ko'p iste'molchi bog'liq)
  - Misol: order.created.v1 (boshqa service tinglaydi)
  - Uzatuv: broker (asinxron, tarmoq orqali)

   QOIDA: domain event'ni TO'G'RIDAN tashqariga chiqarma!
  Domain event  (mapping)  integration event  broker
  Sabab: ichki modelni tashqariga oshkor qilsang — barcha iste'molchi
  ichki o'zgarishingga bog'lanib qoladi (coupling qaytadi).

  MUAMMO: distributed tizimda bitta ACID tranzaksiya YO'Q (05-bob, 2PC qimmat).
  Buyurtma = Order + Payment + Inventory (uch service — bir tranzaksiya bo'lmaydi).
  YECHIM: SAGA — mahalliy tranzaksiyalar ketma-ketligi + kompensatsiya (undo).

  IKKI USLUB:

  CHOREOGRAPHY (xoreografiya — markazsiz, event orqali):
  OrderCreated  PaymentService (event tinglaydi)  PaymentCompleted
               InventoryService (tinglaydi)  StockReserved  ...
   Sodda boshlash, markazsiz (bo'shashgan)
   Oqim ko'rinmaydi (kim kimni kutadi?), sikl xavfi, kuzatuv qiyin

  ORCHESTRATION (orkestratsiya — markaziy koordinator):
  Saga Orchestrator: 1) Payment buyur  2) Inventory buyur  3) Ship buyur
  Har qadam muvaffaqiyatsiz  oldingilarni KOMPENSATSIYA (RefundPayment, ReleaseStock)
   Oqim bir joyda ko'rinadi (aniq mantiq), murakkab jarayonga qulay
   Koordinator — markaziy nuqta (murakkablashadi)

   KOMPENSATSIYA — "rollback" emas (event allaqachon bo'lgan) — TESKARI event:
  PaymentCompleted'ni bekor qilmaysiz — RefundIssued qo'shasiz (biznes undo).

  MUAMMO: event'lar MANGU saqlanadi (immutable). Lekin kod o'zgaradi:
  bugun OrderCreated'ga yangi maydon kerak — 2 yil oldingi event'larda u YO'Q.
  Event Sourcing'da eski event'ni O'ZGARTIRIB bo'lmaydi (immutable — 2.2).

  YECHIMLAR:

  1) VERSIYALASH: har event turida version (OrderCreated_v1, v2)
     eventData: { ..., schemaVersion: 2 }

  2) UPCASTING (yuqoriga ko'tarish): o'qishda eski event  yangi shaklga aylantirish
     v1 { total }  upcast  v2 { total, currency: "UZS" }  (default qo'shiladi)
      replay paytida upcaster zanjiri: v1  v2  v3 (joriy)

  3) WEAK SCHEMA: yangi maydon ixtiyoriy (yo'q bo'lsa — default), maydon O'CHIRMA

   QOIDALAR:
  - Yangi maydon — faqat ixtiyoriy (default bilan)
  - Maydon nomini O'ZGARTIRMA / O'CHIRMA (upcaster orqali map qil)
  - Ma'no o'zgarsa — YANGI event turi (eski v1 saqlanadi)

  MUAMMO: broker'lar odatda "AT-LEAST-ONCE" kafolat beradi 9.6-bob:
  event KAMIDA bir marta, lekin ba'zan IKKI marta keladi (retry, tarmoq).
   PaymentReceived ikki marta  ikki marta pul yechish (XATO!)

  YECHIM: IDEMPOTENT CONSUMER — bir event'ni ikki marta qayta ishlash =
  bir marta qayta ishlash (natija bir xil).

  1) EVENT ID + "qayta ishlangan" jadvali (processed_events):
     - event keldi  id processed_events'da bormi?
     - HA  tashla (allaqachon ishlangan)
     - YO'Q  ishla + id ni SHU tranzaksiyada yoz (atomik)

  2) Tabiiy idempotentlik: UPSERT (INSERT ... ON CONFLICT), SET (nv qo'shish emas)

   8.20 (idempotency) bilan bir tamoyil — bu yerda event iste'molida.
  Distributed EDA'da idempotentlik — MAJBURIY (ixtiyoriy emas).

  ZIDDIYAT: Event Sourcing — event MANGU, immutable (o'chirmaslik — asos).
  GDPR (va shaxsiy ma'lumot qonunlari) — "o'chirish huquqi" (right to erasure).
   Foydalanuvchi "ma'lumotimni o'chir" desa, lekin event store o'chirmasa — muammo.

  YECHIMLAR:

  1) CRYPTO-SHREDDING (kripto-parchalash — eng keng tarqalgan):
     Shaxsiy ma'lumotni event ichida SHIFRLAB saqlash (har foydalanuvchi — kalit)
     "O'chirish" = KALITNI o'chirish  shifrlangan ma'lumot O'QIB BO'LMAYDI
      Event immutable qoladi, lekin shaxsiy ma'lumot amalda yo'qoladi

  2) Shaxsiy ma'lumotni event'dan TASHQARIDA (alohida jadval — o'chsa bo'ladi)
     Event'da faqat ID; shaxsiy ma'lumot alohida (an'anaviy o'chirish)

   Event Sourcing tanlashdan OLDIN GDPR'ni o'yla (shaxsiy ma'lumot bo'lsa).
  Bu — Event Sourcing'ning jiddiy amaliy kamchiligi 2.6-bob.

   EDA — bo'shashgan bog'lanish (event — domain event 9.4, queue 9.6)
   Event = o'tgan zamon, immutable (fakt — 2.2)
   CQRS — o'qish/yozish juda farq qilganda (oddiy CRUD'ga emas — 2.4, 2.10)
   Event Sourcing — audit/tarix/vaqt sayohati kerak bo'lganda (2.6, 2.10)
   Eventual consistency — biznes toqat qilsa 2.7-bob
   Outbox pattern (ishonchli event — dual write — 2.8)
   Boshla: EDA  CQRS  ES (bosqichma-bosqich — hammasi birdan emas — 2.9)
   Tracing/monitoring (asinxron kuzatuv — 10, 2.3)
   Idempotent consumer (at-least-once — takror event — 2.16)
   Domain event  integration event map (ichki modelni oshkor qilma — 2.13)
   Event versiyalash + upcasting (schema evolution — 2.15)
   Saga: teskari biznes event bilan kompensatsiya (rollback emas — 2.14)
   Event Sourcing + shaxsiy ma'lumot: crypto-shredding (GDPR — 2.17)
   Over-engineering'dan qoch (CRUD yetsa — CRUD — 2.10)

EDA 2.1-bob: emit(event)  event bus  ko'p tinglovchi (bo'shashgan)
CQRS 2.4-bob: Command (yozish, write model) | Query (o'qish, read model)
Event Sourcing 2.6-bob: event store (event'lar)  replay  holat
Eventual consistency 2.7-bob: yozish  read model biroz keyin
Outbox 2.8-bob: bir tranzaksiya (ma'lumot + event jadvali)  keyin queue
Uch uslub 2.12-bob: notification (signal) | state transfer (to'liq) | sourcing
Saga 2.14-bob: choreography (markazsiz) | orchestration (koordinator) + kompensatsiya
Upcasting 2.15-bob: eski event  o'qishda yangi shakl (event O'ZGARMAYDI)
Idempotent 2.16-bob: event ID + processed_events (takror = bir marta)

NestJS 2.11-bob: @CommandHandler | @QueryHandler | @EventsHandler

// NestJS EventEmitter 8.16-bob — bo'shashgan bog'lanish
@Injectable()
export class OrderService {
  constructor(private eventEmitter: EventEmitter2) {}

  async yarat(dto: any) {
    const order = await this.repo.save(dto);
    // Event e'lon (tinglovchilarni BILMAYDI — 2.1)
    this.eventEmitter.emit("order.created", new OrderCreatedEvent(order.id, order.userId));
    return order;
  }
}

// Tinglovchilar (mustaqil — OrderService ularni bilmaydi)
@Injectable()
export class NotificationListener {
  @OnEvent("order.created")
  async handle(event: OrderCreatedEvent) { await this.notify.yubor(event.userId); }
}
@Injectable()
export class AnalyticsListener {
  @OnEvent("order.created")
  async handle(event: OrderCreatedEvent) { await this.analytics.yoz(event); }
}
//  Yangi tinglovchi qo'shish — OrderService o'zgarmaydi (OCP — 9.1)

// Event — o'tgan zamon, o'zgarmas (fakt)
export class OrderCreatedEvent {
  public readonly occurredAt: Date;                   // qachon bo'ldi
  constructor(
    public readonly orderId: string,
    public readonly userId: string,
    public readonly summa: number,
  ) {
    this.occurredAt = new Date();
    Object.freeze(this);                              // immutable (fakt — o'zgarmas)
  }
}
//  Event NOM — o'tgan zamon (OrderCreated, PaymentReceived — "bo'ldi")
// Command NOM — buyruq (CreateOrder, ProcessPayment — "qil")

// === COMMAND (yozish) ===
export class CreateOrderCommand {
  constructor(public readonly userId: string, public readonly items: any[]) {}
}

@CommandHandler(CreateOrderCommand)
export class CreateOrderHandler implements ICommandHandler<CreateOrderCommand> {
  constructor(
    @InjectRepository(Order) private writeRepo: Repository<Order>,
    private eventBus: EventBus,
  ) {}
  async execute(cmd: CreateOrderCommand) {
    // Write model — biznes qoidalar, tranzaksiya (6.9)
    const order = await this.writeRepo.save({ userId: cmd.userId, items: cmd.items });
    this.eventBus.publish(new OrderCreatedEvent(order.id, cmd.userId, order.summa));   // event
    return order.id;
  }
}

// === QUERY (o'qish) ===
export class GetUserOrdersQuery {
  constructor(public readonly userId: string) {}
}

@QueryHandler(GetUserOrdersQuery)
export class GetUserOrdersHandler implements IQueryHandler<GetUserOrdersQuery> {
  constructor(@InjectRepository(OrderReadModel) private readRepo: Repository<OrderReadModel>) {}
  async execute(query: GetUserOrdersQuery) {
    return this.readRepo.find({ where: { userId: query.userId } });   // read model (tez, tayyor)
  }
}

// Controller
@Controller("orders")
export class OrdersController {
  constructor(private commandBus: CommandBus, private queryBus: QueryBus) {}
  @Post() yarat(@Body() dto: any) { return this.commandBus.execute(new CreateOrderCommand(dto.userId, dto.items)); }
  @Get() olish(@Query("userId") userId: string) { return this.queryBus.execute(new GetUserOrdersQuery(userId)); }
}

// Event  read model yangilash (denormalized — tez o'qish)
@EventsHandler(OrderCreatedEvent)
export class OrderProjection implements IEventHandler<OrderCreatedEvent> {
  constructor(
    @InjectRepository(OrderReadModel) private readRepo: Repository<OrderReadModel>,
    private usersService: UsersService,
  ) {}

  async handle(event: OrderCreatedEvent) {
    // Read model — DENORMALIZED (JOIN'siz, tez o'qish — 2.5)
    const user = await this.usersService.bitta(event.userId);
    await this.readRepo.save({
      orderId: event.orderId,
      userId: event.userId,
      userIsm: user.ism,                              // denormalized (oldindan qo'shilgan)
      summa: event.summa,
      sana: event.occurredAt,
    });
    //  endi o'qishda JOIN kerak emas (tayyor — tez)
  }
}
//  Read model EVENTUAL (event kelganda yangilanadi — 2.7)

// Event store — barcha event'lar (holat emas — 2.6)
@Entity("event_store")
export class StoredEvent {
  @PrimaryGeneratedColumn("uuid") id: string;
  @Column() aggregateId: string;                      // qaysi obyekt (account)
  @Column() eventType: string;                        // MoneyDeposited, MoneyWithdrawn
  @Column("jsonb") eventData: any;
  @Column() version: number;                          // tartib
  @CreateDateColumn() occurredAt: Date;
}

@Injectable()
export class AccountEventStore {
  // Event qo'shish (immutable — faqat append)
  async append(aggregateId: string, event: any) {
    await this.repo.save({
      aggregateId, eventType: event.constructor.name, eventData: event,
      version: await this.nextVersion(aggregateId),
    });
  }

  // Holatni REPLAY (event'lar yig'indisi — 2.6)
  async getBalance(accountId: string): Promise<number> {
    const events = await this.repo.find({
      where: { aggregateId: accountId }, order: { version: "ASC" },
    });
    return events.reduce((balans, e) => {             // event'larni "o'ynash"
      if (e.eventType === "MoneyDeposited") return balans + e.eventData.miqdor;
      if (e.eventType === "MoneyWithdrawn") return balans - e.eventData.miqdor;
      return balans;
    }, 0);                                            // boshlang'ich 0  yig'indi = balans
  }
}

// MUAMMO: 1M event'ni har safar replay — sekin
// YECHIM: snapshot (vaqti-vaqti holatni saqlash)
@Injectable()
export class AccountService {
  async getBalance(accountId: string): Promise<number> {
    // Oxirgi snapshot'dan boshlash (hamma event emas)
    const snapshot = await this.snapshotRepo.findOne({
      where: { accountId }, order: { version: "DESC" },
    });
    const fromVersion = snapshot?.version || 0;
    let balans = snapshot?.balans || 0;

    // Faqat snapshot'dan keyingi event'larni replay (tez)
    const events = await this.eventStore.getEventsAfter(accountId, fromVersion);
    for (const e of events) balans = this.apply(balans, e);
    return balans;
  }
  // Har 100 event — yangi snapshot (cron yoki yozishda)
}
//  Snapshot — Event Sourcing'ni tez qiladi (replay qisqaradi)

// DB + event ATOMIK (dual write muammosi yechimi — 2.8)
@Injectable()
export class OrderService {
  async yarat(dto: any) {
    return this.dataSource.transaction(async (manager) => {   // BIR tranzaksiya (ACID — 6.9)
      // 1. Biznes ma'lumot
      const order = await manager.save(Order, dto);
      // 2. Event SHU tranzaksiyada outbox jadvaliga (atomik!)
      await manager.save(OutboxEvent, {
        eventType: "OrderCreated",
        payload: { orderId: order.id },
        status: "pending",
      });
      return order;                                   // ikkalasi yoki hech narsa
    });
  }
}

// Alohida jarayon — outbox'ni queue'ga yuboradi (cron/poll — 8.18)
@Injectable()
export class OutboxPublisher {
  @Interval(5000)
  async publish() {
    const events = await this.outboxRepo.find({ where: { status: "pending" }, take: 100 });
    for (const e of events) {
      await this.queue.emit(e.eventType, e.payload);  // queue'ga (9.6)
      await this.outboxRepo.update(e.id, { status: "published" });   // belgilash
    }
  }
}
//  DB saqlandi  event ham saqlandi (outbox)  yo'qolmaydi (yiqilsa, keyin yuboriladi)

// Yozishdan keyin darrov javob (read model kutmasdan — 2.7)
@Post("orders")
async yarat(@Body() dto: any) {
  const orderId = await this.commandBus.execute(new CreateOrderCommand(dto.userId, dto.items));
  // Read model hali yangilanmagan bo'lishi mumkin (eventual)
  //  write natijasini darrov qaytarish (read'siz — stale oldini olish)
  return {
    orderId,
    status: "created",
    // Frontend bu ma'lumot bilan ishlaydi (read model keyin yangilanadi)
  };
}
// Frontend: optimistik UI (darrov ko'rsatadi)  read model yangilangach moslaydi
// yoki: orderId bilan poll (read model tayyor bo'lguncha)

// Mikroservisda EDA — Kafka event (9.6)
// Order xizmat — event chiqaradi
@Injectable()
export class OrderService {
  constructor(@Inject("KAFKA") private kafka: ClientKafka) {}
  async yarat(dto: any) {
    const order = await this.repo.save(dto);
    this.kafka.emit("order.events", { type: "OrderCreated", orderId: order.id });   // (9.6: 2.6)
    return order;
  }
}

// Boshqa xizmatlar tinglaydi (mustaqil — distributed EDA)
@EventPattern("order.events")
async handle(@Payload() event: any) {
  if (event.type === "OrderCreated") {
    await this.inventoryService.zaxiraKamaytir(event.orderId);   // mustaqil reaksiya
  }
}
//  Monolitda EventEmitter (Misol 1); mikroservisda Kafka (bo'shashgan — 9.6)

  ARXITEKTURA NAQSHI QARORI:

  Loyiha — oddiy CRUD?
  └─ HA  oddiy service 8.1-bob — CQRS/ES/EDA KERAK EMAS (over-engineering)

  Ko'p reaksiya kerak (notification, integratsiya, mustaqil qism)?
  └─ HA  EDA (event-driven — domain event — 9.4, queue — 9.6)

  O'qish/yozish yuki yoki modeli juda farqmi?
  └─ HA  CQRS (read/write ajratish)

  To'liq audit, "nima bo'lgan", vaqt sayohati kerakmi (bank, moliyaviy)?
  └─ HA  Event Sourcing (event store)

  Biznes eventual consistency'ga toqat qiladimi?
  ├─ HA  CQRS/EDA mumkin
  └─ YO'Q (strong consistency majburiy)  monolit/ACID (6.9)

   Boshla oddiy (CRUD/EDA)  murakkab (CQRS/ES) kerak bo'lganda

// At-least-once broker 9.6-bob  event ba'zan IKKI marta keladi  idempotentlik shart
@Injectable()
export class PaymentConsumer {
  constructor(private dataSource: DataSource) {}

  @EventPattern("payment.received")
  async handle(@Payload() event: { eventId: string; orderId: string; summa: number }) {
    await this.dataSource.transaction(async (manager) => {
      // 1. Bu event ID allaqachon ishlanganmi? (processed_events jadvali)
      const already = await manager.findOne(ProcessedEvent, { where: { eventId: event.eventId } });
      if (already) return;                              // takror — tashla (idempotent)

      // 2. Biznes ishi + event ID belgisi — BIR tranzaksiyada (atomik — 2.8)
      await manager.update(Order, { id: event.orderId }, { status: "paid" });
      await manager.save(ProcessedEvent, { eventId: event.eventId });
    });
  }
}
//  Ikki marta kelsa ham — natija bir xil (bir marta "paid"). Distributed EDA'da MAJBURIY.

// Eski event'ni O'ZGARTIRMAY, o'qishda yangi shaklga ko'tarish (upcast — 2.15)
// v1: { total }      v2: { total, currency }
type UpcasterFn = (data: any) => any;

const upcasters: Record<string, Record<number, UpcasterFn>> = {
  OrderCreated: {
    1: (d) => ({ ...d, currency: "UZS" }),            // v1  v2: default currency qo'shildi
    2: (d) => ({ ...d, source: "web" }),              // v2  v3: default source qo'shildi
  },
};

// Replay paytida event'ni joriy versiyaga ko'tarish (zanjir: v1v2v3)
function upcast(eventType: string, data: any, fromVersion: number, toVersion: number): any {
  let result = data;
  for (let v = fromVersion; v < toVersion; v++) {
    const fn = upcasters[eventType]?.[v];
    if (fn) result = fn(result);                       // har bosqichda default to'ldiriladi
  }
  return result;
}
//  Event store O'ZGARMAYDI (immutable — 2.2); upcaster faqat O'QISHDA (replay) ishlaydi.
// Bu — Event Sourcing'da "jadval migratsiyasi" o'rnini bosadi (ALTER emas — upcaster).

// Markaziy koordinator: qadamlar + xatolikda kompensatsiya (biznes undo — 2.14)
@Injectable()
export class CreateOrderSaga {
  constructor(
    private payment: PaymentService,
    private inventory: InventoryService,
  ) {}

  async run(order: Order) {
    const bajarilgan: string[] = [];                   // kompensatsiya uchun kuzatuv
    try {
      await this.payment.charge(order);   bajarilgan.push("payment");   // 1-qadam
      await this.inventory.reserve(order); bajarilgan.push("inventory"); // 2-qadam
      // ... barcha qadam muvaffaqiyatli  saga tugadi
    } catch (err) {
      // Xatolik  BAJARILGAN qadamlarni TESKARI tartibda kompensatsiya (rollback emas — 2.14)
      if (bajarilgan.includes("inventory")) await this.inventory.release(order);  // StockReleased
      if (bajarilgan.includes("payment"))   await this.payment.refund(order);     // RefundIssued
      throw err;
    }
  }
}
//  Kompensatsiya — DB rollback emas (qadam bo'lib bo'lgan) — TESKARI biznes event.
// Choreography muqobili: har service event tinglaydi (markazsiz — 2.14).

 oddiy ma'lumotga event sourcing (over-engineering — 2.10)
 oddiy service (CRUD)

 saqlangan event'ni tahrirlash (fakt emas — 2.2)
 immutable (yangi event qo'shish)

 DB saqla + event yubor (atomik emas — yo'qolishi — 2.8)
 Outbox pattern (bir tranzaksiya)

 yozgach darrov read'dan o'qish (stale — 2.7)
 write natijasi / optimistik UI / poll

 bank balansiga eventual (xato — 2.7)
 strong consistency (ACID — monolit)

 consumer takror event'ni qayta ishlaydi (ikki marta pul — 2.16)
 idempotent consumer (event ID + processed_events — Misol 11)

 ichki domain event broker'ga (iste'molchi ichki modelga bog'lanadi — 2.13)
 integration event'ga map (publik, versiyalangan shartnoma)

 saga xatosida "rollback" (event bo'lib bo'lgan — 2.14)
 teskari biznes event (RefundIssued, StockReleased)