Bounded Context — Domain-Driven Designda muayyan domen modeli va uning ubiquitous language atamalari aniq ma’noga ega bo‘lgan chegara hisoblanadi. Chegara ichida obyektlar, qoidalar va nomlar izchil talqin qilinadi; boshqa kontekstga o‘tilganda bir xil so‘z boshqa modelni anglatishi mumkin. Bu murakkab tizimni bitta ulkan universal modelga aylantirmaslikka yordam beradi.
Chegaraning tabiati
Bounded Context faqat mikroxizmat yoki kod papkasi emas. U semantik va model chegarasidir. Ba’zan bitta kontekst alohida servisga joylashadi, ba’zan modul monolit ichida mavjud bo‘ladi. Aksincha, bitta servis ichida bir necha aralash model bo‘lsa, deployment birligi ularni mantiqan bitta kontekstga aylantirmaydi.
Chegara jamoa mas’uliyati, ma’lumot modeli, API va release jarayoni bilan mustahkamlanishi mumkin. Muhim jihat shuki, model elementlari qayerda amal qilishi ochiq bo‘ladi. Masalan, Product katalog kontekstida tavsif va kategoriya bilan, ombor kontekstida esa SKU, qoldiq va joylashuv bilan ifodalanadi.
Kontekstni aniqlash
Tahlil paytida biznes capability, jarayon, atamalar va o‘zgarish tezligi o‘rganiladi. Bir xil nom turli qoida bilan ishlatilsa yoki bir bo‘limdagi o‘zgarish boshqasiga doim zarar yetkazsa, alohida kontekst zarur bo‘lishi mumkin. Chegara tashkilot diagrammasini ko‘r-ko‘rona takrorlamaydi; real domen bog‘liqligi asosida tanlanadi.
Juda yirik kontekst ichki modelni tushunishni qiyinlashtiradi. Juda mayda kontekstlar esa ko‘p tarmoq chaqiruvi, ma’lumot izchilligi va operatsion xarajat keltiradi. Chegara mustaqil biznes ma’nosi va o‘zgarish sabablariga qarab muvozanatlanadi.
Context map
Context map kontekstlar o‘rtasidagi aloqani va ta’sir yo‘nalishini ko‘rsatadi. Upstream model ma’lumot yoki xizmat beradi, downstream undan foydalanadi. Customer–supplier munosabatida tomonlar interfeys haqida kelishadi. Conformist holatida downstream upstream modelini qabul qiladi. Anticorruption layer esa tashqi modelni ichki tilga tarjima qiladi.
Shared kernel ikki kontekstga kichik umumiy modelni birga boshqarish imkonini beradi, lekin har o‘zgarish muvofiqlashtirishni talab qiladi. Open host service barqaror protokol taqdim etadi, published language esa almashinuv formatini kelishilgan tilda ifodalaydi. Aloqa turi hujjatlashtirilmasa, yashirin bog‘liqlik paydo bo‘ladi.
Ma’lumot almashinuvi
Kontekstlar API, xabar yoki replikatsiya orqali hamkorlik qiladi. Bir kontekstning ichki database jadvaliga boshqasining bevosita yozishi chegarani buzadi. API contract yoki event payload faqat kerakli ma’lumotni chiqaradi va ichki modelni erkin rivojlantirishga imkon beradi.
Tarqatilgan tizimda barcha kontekst bir transaction ichida yangilanmasligi mumkin. Eventual consistency, idempotent consumer va kompensatsiya jarayonlari qo‘llanadi. Qaysi invariant aynan bitta kontekst ichida darhol saqlanishi kerakligi model dizaynining muhim qaroridir.
Tashkiliy oqibatlar
Kontekstga aniq egalik berilsa, jamoa model va API evolyutsiyasiga mas’ul bo‘ladi. Bir jadval yoki classga ko‘p jamoa mustaqil o‘zgartirish kiritsa, chegaralar amalda ishlamaydi. Versiyalash, contract test va observability kontekstlararo integratsiyani nazorat qiladi.
Bounded Context mikroxizmatlarga avtomatik bo‘lib tashlash retsepti emas. Avval semantik chegaralar aniqlanadi; fizik ajratish esa yuklama, mustaqil release, xavfsizlik va operatsion imkoniyat asosida tanlanadi.
Chegarani tekshirish
Kontekstning ichki modeli tashqi jamoalarga tez-tez sizib chiqsa yoki har o‘zgarish bir nechta mustaqil releaseni majbur qilsa, aloqa qayta ko‘riladi. Contract testlar integratsiya formatini, arxitektura testlari esa taqiqlangan modul bog‘lanishlarini tekshirishi mumkin. Monitoringdagi servis nomlari ham context ownershipni ko‘rsatadi.
Bog‘liq tushunchalar
Domain-Driven Design, Ubiquitous language, Context map, Aggregate, Anticorruption layer, Domain event