Clean Architecture — toza, saqlanadigan kod tuzilmasi

Odatiy kodda biznes mantig‘i framework va bazaga chirmashib ketadi: buyurtma qoidalari NestJS controller ichida, to‘g‘ridan-to‘g‘ri Prisma’ga bog‘langan.

Clean Architecture (Robert C. Martin) — konsentrik doiralar. Yagona qoida: manba kodi bog‘liqliklari ichkariga qaraydi (The Dependency Rule).

Ichki qatlamlar tashqi qatlamlar haqida hech narsa bilmaydi. Domain — Prisma, NestJS, HTTP mavjudligini ham bilmaydi. Tashqi qatlamlar (DB, web) esa ichki qatlamga bog‘lanadi. Bu — arxitekturaning butun mohiyati.

Har qatlam aniq javobgarlikka ega:

Buni amalga oshiruvchi mexanizm — Ports & Adapters: use case interfeysga (port) bog‘lanadi, infratuzilma esa uni amalga oshiradi (adapter). NestJS DI ularni ulaydi.

1 · Domain — sof qoidalar

// DOMAIN — sof biznes qoidalari, framework/DB YO'Q
export class Order {
  constructor(
    public readonly id: string,
    public status: "draft" | "confirmed" | "cancelled",
    private items: OrderItem[],
  ) {}

  cancel() {   // biznes qoidasi shu yerda -> DB'siz, HTTP'siz test qilinadi
    if (this.status === "confirmed") throw new Error("Tasdiqlangan buyurtma bekor bo'lmaydi");
    this.status = "cancelled";
  }
}

2 · Port + Use Case — interfeysga bog‘liq

// PORT — use case KERAK bo'lgan interfeys (biznes tomonda aniqlanadi)
export abstract class OrderRepository {
  abstract findById(id: string): Promise<Order | null>;
  abstract save(order: Order): Promise<void>;
}

// USE CASE — PORT'ga bog'liq, Prisma'ni BILMAYDI
@Injectable()
export class CancelOrderUseCase {
  constructor(private readonly orders: OrderRepository) {}   // interfeys, konkret emas!

  async execute(orderId: string) {
    const order = await this.orders.findById(orderId);
    if (!order) throw new NotFoundException();
    order.cancel();                    // domen qoidasi
    await this.orders.save(order);
  }
}

3 · Adapter + DI — infratuzilma portni amalga oshiradi

// ADAPTER — infratuzilma; PORT'ni Prisma bilan amalga oshiradi (tashqi qatlam)
@Injectable()
export class PrismaOrderRepository extends OrderRepository {
  constructor(private prisma: PrismaService) { super(); }

  async findById(id: string): Promise<Order | null> {
    const row = await this.prisma.order.findUnique({ where: { id } });
    return row ? new Order(row.id, row.status as any, row.items) : null;   // DB -> domen
  }
  async save(order: Order): Promise<void> {
    await this.prisma.order.update({ where: { id: order.id }, data: { status: order.status } });
  }
}

// NestJS DI — interfeysga konkret implementatsiyani bog'laymiz
@Module({
  providers: [
    CancelOrderUseCase,
    { provide: OrderRepository, useClass: PrismaOrderRepository },   // port -> adapter
  ],
})
export class OrdersModule {}

Tabiiy bog‘liqlikni "ag‘darish"

Tabiiy holatda biznes mantig‘i DB’ga bog‘lanadi (biznes → Prisma). DIP buni ag‘daradi: ikkalasi ham biznes belgilagan interfeysga bog‘lanadi. Endi DB biznesga bog‘liq, aksincha emas:

Yuqori daraja (biznes) va past daraja (DB) endi bir-biriga emas, abstraksiyaga (interfeys) bog‘lanadi. Va o‘sha interfeysni biznes belgilaydi (o‘ziga nima kerakligini). Shu tufayli detallar (DB, framework) chinakam almashtiriladigan bo‘ladi.

• Clean Architecture = kodni biznes markazda, framework/DB tashqarida tashkil qilish. Yagona qoida: bog‘liqliklar ichkariga (biznesga) qaraydi.
• Qatlamlar: Domain (sof qoidalar) → Use Cases (jarayon) → Adapters (tarjima) → Infrastructure (DB, web — detal). Ichki qatlam tashqarini bilmaydi.
• Mexanizm — Ports & Adapters: use case interfeysga (port) bog‘lanadi; infratuzilma uni amalga oshiradi (adapter). NestJS DI ulaydi.
• Yuragi — DIP: abstraksiyaga bog‘lan, konkretga emas; interfeysni biznes belgilaydi → DB detalga aylanadi.
• Foyda: testlanadigan, almashtiriladigan, aniq. Narxi: boilerplate, bilvositalik. Mutanosib qo‘lla — CRUD uchun ortiqcha, murakkab domenda bebaho.