Architecture — dasturiy tizimning yirik qismlari, ular orasidagi aloqalar va asosiy texnik qarorlarni ifodalovchi tuzilishdir. U alohida klass yoki funksiyaning kodidan ko‘ra kengroq ko‘lamga ega: tizim qaysi komponentlarga bo‘linishi, ma’lumot qayerdan o‘tishi, qaysi interfeyslar barqaror saqlanishi va sifat talablariga qanday erishilishi architecture doirasida belgilanadi.
Tuzilma va qarorlar
Arxitektura diagrammadagi qutilar yig‘indisi emas. Muhim qarorlar ko‘pincha keyin o‘zgartirish qimmat bo‘lgan xususiyatlarga taalluqlidir. Ma’lumotlar bazasi turi, xizmatlar chegarasi, autentifikatsiya usuli, sinxron yoki asinxron aloqa, deploy modeli shular jumlasiga kiradi. Qaror muayyan talab va cheklovga tayanadi; shu sababli bir loyiha uchun to‘g‘ri yechim boshqasida ortiqcha murakkablik bo‘lishi mumkin.
Keng tarqalgan uslublar
- Layered architecture taqdimot, biznes mantiqi va ma’lumot qatlamlarini ajratadi.
- Hexagonal architecture biznes yadrosini tashqi baza, HTTP yoki xabar tizimidan port va adapterlar orqali ajratadi.
- Event-driven architecture komponentlar o‘rtasidagi aloqani voqealar orqali tashkil etadi.
- Microservices architecture tizimni mustaqil deploy qilinadigan xizmatlarga bo‘ladi.
- Monolithic architecture funksiyalarni bitta deploy birligida saqlaydi, ichki modullarga bo‘linishi mumkin.
Bu uslublar qat’iy tayyor qolip emas. Amaliy tizim bir nechta yondashuvni turli chegaralarda birlashtirishi mumkin.
Sifat atributlari
Architecture funksiyalar bilan birga nofunksional xususiyatlarni ham shakllantiradi. Scalability yuklama oshganda tizimning kengayishini, availability nosozlik paytida xizmatning davom etishini, maintainability kodni o‘zgartirish qulayligini bildiradi. Xavfsizlik, kuzatuvchanlik, kechikish va xarajat ham muhim atributlardir.
Atributlar orasida murosa mavjud. Kuchli izchillik ma’lumotning bir xil ko‘rinishini beradi, lekin tarmoq bo‘linishida mavjudlikni cheklashi mumkin. Ko‘p mustaqil xizmat deploy erkinligini oshiradi, biroq tarmoq chaqiruvlari, monitoring va ma’lumot tranzaksiyalarini murakkablashtiradi.
Arxitektura chegaralari
Komponent chegarasi javobgarlik va ma’lumot egaligiga asoslanadi. Yaxshi chegarada ichki o‘zgarish tashqi iste’molchiga kam ta’sir qiladi. Buning uchun API yoki voqea sxemasi aniq shartnoma sifatida ishlaydi. Bog‘lanish haddan tashqari kuchli bo‘lsa, bitta o‘zgarish ko‘plab modullarni bir vaqtda yangilashni talab qiladi.
Hujjatlash
Architecture Decision Record qisqa hujjat bo‘lib, muammo, tanlangan qaror, muqobil variant va oqibatlarni qayd etadi. C4 kabi diagramma usullari tizimni kontekst, konteyner, komponent va kod darajalarida ko‘rsatadi. Hujjat amaldagi tizimdan uzilib qolmasligi uchun muhim o‘zgarishlar bilan yangilanadi.
Architecture vaqt o‘tishi bilan rivojlanadi. Yuklama, jamoa tarkibi yoki biznes talabi o‘zgarganda avvalgi qaror qayta ko‘rib chiqilishi mumkin. Shunday evolyutsiya tasodifiy emas, kuzatiladigan sifat ko‘rsatkichlari va aniq ehtiyoj asosida amalga oshiriladi.
Evolyutsion o‘zgarish
Arxitekturani almashtirish ko‘pincha birdan bajarilmaydi. Strangler pattern eski tizim yonida yangi komponent yaratib, trafik yoki funksiyalarni bosqichma-bosqich ko‘chirishga imkon beradi. API versiyasi va ma’lumot migratsiyasi eski iste’molchilar ishlashini vaqtincha saqlaydi. Har bosqichda kuzatuv ko‘rsatkichi va rollback yo‘li bo‘lsa, o‘zgarish xavfi kamayadi. Architecture fitness function deb ataladigan avtomatik tekshiruvlar qatlamlar orasidagi taqiqlangan bog‘lanish, dependency yo‘nalishi yoki latency chegarasini build jarayonida nazorat qilishi mumkin. Shunda arxitektura faqat hujjatdagi niyat emas, kod va ishlab chiqarish xatti-harakatida tekshiriladigan cheklovga aylanadi.
Conway qonuni
Tizim modullari ko‘pincha uni yaratgan jamoalarning aloqa tuzilishiga o‘xshaydi. Bir-biridan mustaqil deploy qilinishi kutilgan xizmatlar uchun mas’uliyat va qaror chegaralari ham mos bo‘lishi kerak. Aks holda arxitektura hujjatda ajratilgan bo‘lsa-da, har o‘zgarish ko‘plab jamoalar kelishuviga bog‘lanadi.
Bog‘liq tushunchalar
system design, software architecture, monolith, microservices, API, scalability, Architecture Decision Record