Coupling — dasturiy komponent, modul yoki xizmatlarning bir-biriga qanchalik va qanday bog‘langanini ifodalovchi tushuncha. Yuqori couplingda bir qismning interfeysi, ma’lumot modeli, vaqt talabi yoki implementatsiyasi o‘zgarsa boshqalarda ko‘p o‘zgarish talab qilinadi. Past coupling mustaqil rivojlanishni osonlashtiradi, ammo barcha bog‘lanishni yo‘qotish mumkin ham, maqsadga muvofiq ham emas.
Bog‘lanish ko‘rinishlari
Coupling faqat import yoki funksiya chaqiruvi emas. U bir necha qatlamda namoyon bo‘ladi:
- compile-time coupling umumiy class, kutubxona yoki typega bog‘lanish;
- data coupling umumiy schema va maydon ma’nosiga bog‘lanish;
- temporal coupling amallar ma’lum tartib yoki vaqtda bajarilishi talabi;
- protocol coupling HTTP, xabar yoki fayl formatiga bog‘lanish;
- deployment coupling komponentlarni bir vaqtda release qilish majburiyati;
- operational coupling umumiy database, queue yoki failure domainni bo‘lishish.
Ikki xizmat alohida repositoryda bo‘lsa ham, har deployni birga qilish talab qilinsa ular deployment bo‘yicha qattiq bog‘langan.
Content va control coupling
Klassik tasnifda content coupling bir modul boshqasining ichki ma’lumoti yoki implementatsiyasiga bevosita aralashganda yuz beradi. Common coupling global state’ni bo‘lishishdir. Control coupling caller flag uzatib, callee ichki algoritmining qaysi branchini bajarishini buyurganda ko‘rinadi. Stamp coupling esa katta data structure berilib, uning kichik qismi ishlatilganda paydo bo‘ladi.
Data coupling faqat kerakli qiymatlar aniq parametrlar orqali uzatiladigan nisbatan yengil bog‘lanishdir. Message coupling komponentlarni immutable xabar contracti bilan ajratishi mumkin, lekin schema va semantika baribir coupling hisoblanadi.
Coupling va cohesion
Cohesion modul ichidagi vazifalarning bir maqsadga tegishliligini bildiradi. Arxitektura odatda modul ichida yuqori cohesion, modullar orasida boshqariladigan past couplingga intiladi. Bir-biriga kuchli tegishli qoidalarni sun’iy alohida xizmatlarga bo‘lish tarmoq couplingini oshirib, cohesionni pasaytirishi mumkin.
Masalan, order invariantini saqlaydigan amallar bir transaction chegarasida bo‘lishi mantiqli. Ularni faqat “microservice ko‘p bo‘lsin” deb ajratish distributed transaction yoki saga talabini tug‘diradi.
Interfeys va ma’lumot egaligi
Barqaror, kichik public interface ichki implementatsiyani yashiradi. Dependency inversion yuqori darajali modulga kerakli portni belgilash imkonini beradi. Biroq interface qo‘yishning o‘zi couplingni yo‘qotmaydi; caller metod va contract ma’nosiga baribir bog‘liq.
Shared database’da bir xizmat boshqasining jadvalini o‘qisa, schema coupling hosil bo‘ladi. API orqali o‘qish ownershipni aniq qiladi, lekin latency va availability couplingini qo‘shadi. Event nusxa ma’lumotni lokal saqlashga imkon beradi, evaziga eventual consistency keladi.
Couplingni aniqlash
Code dependency graph import va circular dependencylarni ko‘rsatadi. Change coupling uchun version-control tarixida qaysi fayl yoki service doimo birga o‘zgargani tahlil qilinadi. Distributed tracing runtime chaqiruv zanjiri va fan-outni ko‘rsatadi. Incidentda bir xizmat nosozligi qancha downstreamga tarqalgani operational couplingni ochadi.
Maqsad eng kichik raqam emas, biznes va failure boundaryga mos bog‘lanishdir. Contract versioning, timeout, bulkhead va backward compatibility coupling oqibatini boshqaradi.
Vaqt bo‘yicha bog‘lanish
Temporal couplingda caller va callee ayni paytda available bo‘lishi kerak. Synchronous RPC bunga misol. Queue producerga consumer vaqtincha offline bo‘lsa ham yozish imkonini beradi, lekin broker availabilitysi, schema va retentionga yangi bog‘lanish qo‘shadi. Shuningdek, commandlar qat’iy tartibda bajarilishi talab qilinsa, asinxron aloqa ham temporal couplingni butunlay yo‘qotmaydi.
Bog‘liq tushunchalar
Cohesion, Dependency inversion, Service boundary, API contract, Distributed monolith, Modular monolith