Modulli monolit — soddalik bilan tartib

1-mavzuda mikroservisni ko‘rdik. Lekin kichik jamoa uchun u juda murakkab va qimmat: tarmoq, taqsimlangan tranzaksiya, DevOps, monitoring — hammasi birdan yelkangga tushadi. Ikkinchi tomonda esa oddiy monolit bor.

Modul = bitta biznes domeni (bounded context): Users, Orders, Billing, Catalog. Har bir modul o‘z ichida to‘liq: controller + service + repository + tiplar.

3 ta oltin qoida

1. Yagona public eshik. Modul tashqariga faqat bitta serviceni ochadi (masalan UsersService). Repository, entity, ichki yordamchilar — yashirin.

2. Modullar faqat public service orqali gaplashadi. Bir modul boshqasining ichki kodi yoki jadvaliga hech qachon to‘g‘ridan-to‘g‘ri tegmaydi.

3. Har modul o‘z ma’lumotiga egalik qiladi. Bitta baza, lekin har modulning o‘z sxemasi/jadvallari bor; modul faqat o‘ziniki bilan ishlaydi.

NestJS aynan shu uchun yaratilgan — modul tabiiy ravishda enkapsulyatsiya beradi. Providerlar standart holatda private; faqat exportsdagilar ko‘rinadi:

// modules/users/users.module.ts
@Module({
  providers: [UsersService, UsersRepository],  // ikkalasi ham modul ICHIDA
  exports: [UsersService],                      // FAQAT shu tashqariga ko'rinadi
})
export class UsersModule {}
// UsersRepository eksport QILINMAGAN -> boshqa modul uni inject qila OLMAYDI

Eng katta xavf — vaqt o‘tib chegaralar buzilib, yana “loy to‘pi”ga aylanish. Buni oldini olishning aniq texnikalari bor.

1 · Barrel fayl — public kontrakt

Har modulga index.ts qo‘yib, tashqariga nimaning ko‘rinishini bitta joyda belgilaysan. Qolgani import qilinmaydi:

// modules/users/index.ts — modulning YAGONA "public kontrakti"
export { UsersModule } from './users.module';
export { UsersService } from './users.service';
export type { User } from './user.types';
// repository, entity, mapper, internal util — BU YERDA YO'Q (yashirin)

2 · Modullararo aloqa — faqat public service orqali

// modules/orders/orders.module.ts
@Module({
  imports: [UsersModule],            // Users modulining public eshigini olamiz
  providers: [OrdersService, OrdersRepository],
})
export class OrdersModule {}

// modules/orders/orders.service.ts
@Injectable()
export class OrdersService {
  constructor(
    private readonly orders: OrdersRepository,   // O'Z repository (ruxsat ✓)
    private readonly users: UsersService,        // boshqa modul: PUBLIC service ✓
  ) {}

  async create(dto: CreateOrderDto) {
    // Boshqa modul bazasiga TEGMAYMIZ — uning public service'i orqali so'raymiz
    const user = await this.users.findById(dto.userId);
    if (!user) throw new NotFoundException('Foydalanuvchi topilmadi');
    return this.orders.save({ userId: user.id, items: dto.items });  // faqat O'Z jadvali
  }
}

3 · Ma’lumotni ajratish — sxema bo‘yicha

// prisma/schema.prisma — bitta baza, lekin har modul O'Z sxemasida
datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
  schemas  = ["users", "orders"]      // mantiqiy ajratish
}
generator client { provider = "prisma-client-js"; previewFeatures = ["multiSchema"] }

model User  { id String @id @default(uuid())  name String   @@schema("users")  }
model Order { id String @id @default(uuid())  userId String @@schema("orders") }
// DIQQAT: Order.userId ga users jadvaliga FK QO'YILMAYDI —
// modul chegarasini hurmat qilamiz (kelajakda ajratish oson bo'lsin)

4 · Chegarani avtomatik tekshirish (pro)

Insonning intizomiga ishonma — vositaga ishon. eslint-plugin-boundaries yoki dependency-cruiser bilan qoidani CI’da majburlaysan: masalan “orders moduli users modulining faqat index.tsidan import qila oladi, ichkarisidan emas”. Qoida buzilsa — build yiqiladi.

Mikroservisdan farqli o‘laroq, bu yerda bitta NestJS ilova bor. “Xizmatlar” o‘rniga — bir jarayondagi modullar. Hech qanday transport, port yoki broker yo‘q.

Loyiha tuzilmasi

src/
├── main.ts
├── app.module.ts            # barcha modullarni birlashtiradi
├── shared/                  # umumiy: config, db, guard, util
└── modules/
    ├── users/
    │   ├── index.ts         # PUBLIC kontrakt
    │   ├── users.module.ts
    │   ├── users.controller.ts
    │   ├── users.service.ts        # public
    │   ├── users.repository.ts     # private
    │   └── user.types.ts
    ├── orders/
    │   ├── index.ts
    │   ├── orders.module.ts
    │   ├── orders.controller.ts
    │   ├── orders.service.ts
    │   └── orders.repository.ts
    └── notifications/
        ├── notifications.module.ts
        └── order.listener.ts       # event tinglaydi

Hammasini ulash

// app.module.ts — modullarni yig'amiz, BITTA ilova bo'lib ishga tushadi
@Module({
  imports: [
    SharedModule,
    UsersModule,
    OrdersModule,
    NotificationsModule,
  ],
})
export class AppModule {}

// main.ts — oddiy HTTP ilova (mikroservis EMAS, transport YO'Q)
async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  app.useGlobalPipes(new ValidationPipe({ whitelist: true }));
  await app.listen(3000);
}

Modullararo aloqaning ikki yo‘li bor, va to‘g‘ri tanlash muhim:

Ichki event — NestJS misoli

// modules/orders/orders.service.ts
constructor(
  private readonly orders: OrdersRepository,
  private readonly events: EventEmitter2,        // @nestjs/event-emitter
) {}

async create(dto: CreateOrderDto) {
  const order = await this.orders.save(dto);
  // Modul ichida HODISA tashlaymiz — Orders kim tinglashini bilmaydi
  this.events.emit('order.created', new OrderCreatedEvent(order.id, order.userId));
  return order;
}

// modules/notifications/order.listener.ts — BOSHQA modul, bo'sh bog'langan
@Injectable()
export class OrderListener {
  @OnEvent('order.created')
  async handle(event: OrderCreatedEvent) {
    // email yuborish — Orders moduli bundan butunlay bexabar
    await this.email.sendOrderConfirmation(event.userId, event.orderId);
  }
}

Modulli monolitning eng kuchli va’dasi: “keyin kerak bo‘lsa, oson ajrataman”. Chegaralar toza bo‘lgani uchun, bir modulni mikroservisga ko‘chirish — qayta yozish emas, almashtirish.

1 · Orders portga bog‘lanadi

// modules/orders/ports/users.port.ts — Orders FAQAT shu abstraksiyaga bog'liq
export interface UsersPort {
  findById(id: string): Promise<{ id: string; name: string } | null>;
}
export const USERS_PORT = Symbol('USERS_PORT');

// OrdersService endi konkret UsersService'ni emas, PORT'ni inject qiladi
@Injectable()
export class OrdersService {
  constructor(@Inject(USERS_PORT) private readonly users: UsersPort) {}
  // ... mantiq o'zgarmaydi
}

2 · Bugun — lokal adapter (in-process)

// HOZIR (monolit): lokal adapter — to'g'ridan UsersService'ni chaqiradi
@Injectable()
export class LocalUsersAdapter implements UsersPort {
  constructor(private readonly users: UsersService) {}
  findById(id: string) { return this.users.findById(id); }
}
// orders.module.ts:
providers: [
  OrdersService,
  { provide: USERS_PORT, useClass: LocalUsersAdapter },   // <-- shu ulanadi
]

3 · Ertaga — masofaviy adapter (mikroservis)

// KEYIN (mikroservisga ajratilganda): faqat ADAPTER almashadi
@Injectable()
export class RemoteUsersAdapter implements UsersPort {
  constructor(@Inject('USERS_SERVICE') private readonly client: ClientProxy) {}
  findById(id: string) {
    return firstValueFrom(this.client.send({ cmd: 'get_user' }, id));  // endi tarmoq
  }
}
// orders.module.ts da bitta qator o'zgaradi:
{ provide: USERS_PORT, useClass: RemoteUsersAdapter }
// OrdersService — BIR QATOR HAM o'zgarmaydi ✓

Endi ikkalasini yonma-yon qo‘yamiz. Bu jadval — qaror qabul qilish uchun amaliy xarita:

• Modulli monolit = bitta deploy (monolit soddaligi) + aniq chegaralar (mikroservis tartibi).
• Har modul tashqariga faqat bitta public service ochadi; repo/entity/jadval — yashirin. Chegarani kod va vosita majburlaydi, intizom emas.
• Modullararo: javob kerak bo‘lsa public service chaqiruvi, kerak bo‘lmasa ichki event (EventEmitter2).
• Toza chegara = mikroservisga pog‘onali yo‘l: portga bog‘lan, keyin lokal adapterni masofaviysiga almashtir — biznes mantiq tegilmaydi.
• ~90% loyiha shu yerdan boshlashi kerak. Mikroservis — tashkiliy ehtiyoj paydo bo‘lganda, bittalab ajratib boriladi. “Distributed monolith”dan qoch.