Service boundary — xizmat qaysi biznes mas’uliyati, ma’lumot, invariant va operatsiyalarni o‘z ichiga olishini hamda boshqa qismlar bilan qaysi contract orqali aloqa qilishini belgilovchi arxitektura chegarasi. To‘g‘ri boundary xizmatning mustaqil o‘zgarishi va deployini osonlashtiradi. U faqat API endpointlar ro‘yxati emas; ownership va transaction chegarasini ham anglatadi.
Biznes capability
Boundary ko‘pincha texnik qatlam — controller, repository yoki database turiga emas, biznes capabilityga moslanadi. Masalan, Billing to‘lov va invoice qoidalariga, Catalog mahsulot tavsifiga egalik qiladi. Bir feature uchun doimo ikki xizmatni birga o‘zgartirish talab qilinsa, boundary noto‘g‘ri kesilgan bo‘lishi mumkin.
Domain-driven design bounded context ichida atamalar va model bir ma’noga ega. “Customer” Billingda to‘lov subyekti, Supportda murojaat egasi sifatida boshqa modelga ega bo‘lishi mumkin. Bitta universal shared model xizmatlarni qattiq bog‘laydi.
Invariant va transaction
Bir transactionda doimo atomik saqlanishi kerak bo‘lgan invariantlar odatda bir boundary ichida qoladi. Inventory miqdori manfiy bo‘lmasligi kabi qoida shu ma’lumot egasi tomonidan himoyalanadi. Boshqa xizmat “jadvalga to‘g‘ridan-to‘g‘ri update” qilmaydi.
Bir nechta boundaryni qamrab oladigan workflow saga yoki event orqali muvofiqlashtiriladi. Bunda global darhol consistency o‘rniga oraliq holatlar va compensation mavjud. Agar biznes buni qabul qilmasa, chegarani qayta ko‘rish kerak.
Contract
Service public API, command va event schema orqali tashqi dunyoga chiqadi. Contract stable va versionlangan bo‘ladi. Ichki class, database column va ORM entity contractga sizib chiqsa, ichki refactor consumerlarni buzadi.
Command ownershipni bildiradi: ReserveStockni inventory service bajaradi. Event o‘tgan faktni bildiradi: StockReserved. Consumer eventdan o‘z lokal projectionini qurishi mumkin, ammo producerning ichki yozuv tartibiga bog‘lanmaydi.
Ma’lumot egaligi
Boundary ichidagi xizmat ma’lumotni yozishning yagona egasi bo‘ladi. Read-only replica yoki event nusxa bo‘lishi mumkin, lekin source of truth aniq. Shared database fizik jihatdan ishlatilsa ham, schema va permission bilan ownership ajratiladi.
Cross-service join kerak bo‘lsa API composition, materialized view yoki analytics pipeline ishlatiladi. Har usul latency, freshness va consistency trade-offiga ega. Report uchun operational service database’larini runtime join qilish availability coupling yaratishi mumkin.
Boundaryni baholash
Change history qaysi modullar birga o‘zgarganini, tracing qaysi chaqiruvlar doimo birga bajarilishini, incidentlar failure tarqalishini ko‘rsatadi. Jamoa ownershipi ham Conway qonuni orqali arxitekturaga ta’sir qiladi. Bir service’ga bir nechta jamoa tez-tez to‘qnashsa yoki bitta feature ko‘p jamoani aylanib chiqsa, chegara ish oqimiga mos emas.
Boundary doimiy emas. Merge qilish network murakkabligini kamaytirishi, split esa mustaqil masshtab yoki release berishi mumkin. O‘zgarish contract va ma’lumot migratsiyasi bilan bosqichma-bosqich bajariladi.
Xavfsizlik chegarasi
Service boundary har doim trust boundary emas. Ichki tarmoqdagi chaqiruv ham autentifikatsiya va tenant authorization talab qilishi mumkin. Xizmat o‘z ma’lumotiga kirish siyosatini o‘zi tekshiradi; API gatewaydagi umumiy tekshiruvga yolg‘iz tayanmaydi.
Query chegarasi
Bir sahifa ko‘p xizmat ma’lumotini talab qilsa, frontendning har servicega bevosita fan-out qilishi latency va contract couplingni oshiradi. API composition service, Backend for Frontend yoki read model javobni yig‘ishi mumkin. Read model event orqali yangilansa stale bo‘lishi hujjatlashtiriladi. Command esa ma’lumot egasiga yuborilib, projectionga yozilmaydi.
Boundary va jamoa
Xizmat uchun source, deploy, on-call va SLO ownershipi aniq bo‘lmasa, texnik boundary tashkiliy navbatni yo‘qotmaydi. Bir jamoa boshqaradigan xizmatlar soni operatsion sig‘imiga mos bo‘ladi. Platform jamoasi umumiy runtime beradi, lekin domen incidenti uchun mas’uliyat xizmat egasida qoladi.
Bog‘liq tushunchalar
Bounded context, Microservice architecture, Data ownership, API contract, Coupling, Saga