Layered architecture — dasturiy tizim vazifalarini abstraksiya darajalari bo‘yicha qatlamlarga ajratadigan arxitektura usuli. Har qatlam ma’lum mas’uliyatni bajaradi va odatda o‘zidan pastroq qatlam xizmatidan foydalanadi. Keng tarqalgan ko‘rinishda presentation, application/service, domain/business va data access/infrastructure qatlamlari mavjud.
Qatlamlar vazifasi
Presentation HTTP, UI yoki CLI kirishini qabul qilib, tashqi formatni application commandga aylantiradi. Application qatlami use-case ketma-ketligini boshqaradi, transaction chegarasini va dependency chaqiruvini muvofiqlashtiradi. Domain qatlami biznes qoida va invariantlarni ifodalaydi. Data access repository yoki ORM orqali saqlash tizimi bilan ishlaydi.
Bu nomlar qat’iy standart emas. Uch qatlamli arxitektura presentation, business logic va data qatlamini ajratishi mumkin. Fizik server tierlari bilan mantiqiy layerlar ham boshqa tushuncha: bir process ichida to‘rtta layer, uchta serverda esa boshqa deployment topologiyasi bo‘lishi mumkin.
Yopiq va ochiq qatlam
Closed layer modelida yuqori qatlam faqat bevosita pastdagi qatlamga murojaat qiladi. Presentation data accessni chetlab o‘tmaydi. Bu izchillik va almashtirish nuqtasini beradi, lekin oddiy o‘qish uchun ortiqcha wrapper zanjiri yaratishi mumkin.
Open layer ayrim yuqori qatlamga bir necha past qatlamga bevosita kirishga ruxsat beradi. Qaysi qatlam open ekani arxitektura qoidalarida belgilanadi. Tasodifiy bypass business rule yoki authorizationni chetlab o‘tmasligi kerak.
Dependency yo‘nalishi
An’anaviy layered design yuqoridan pastga dependency qiladi: business service repository interfeys yoki concrete data layerga murojaat qiladi. Dependency inversion qo‘llansa, domain/application portni belgilaydi, infrastructure uni implement qiladi. Bu Hexagonal yoki Clean Architecture bilan yaqinlashadi, ammo qatlamlar vazifasi saqlanadi.
Interface har class uchun mexanik yaratilmaydi. Tashqi tizim, saqlash yoki barqaror boundaryda abstraction foydali. Oddiy ichki value objectni interface ortiga yashirish kodni cho‘zadi.
Afzallik va xarajat
Mas’uliyat ajralishi UI yoki database o‘zgarishini biznes qoidasidan cheklashi, unit testni osonlashtirishi mumkin. Developer qoidaning qaysi qatlamda joylashishini biladi. Security va transaction kabi cross-cutting concern middleware, decorator yoki application boundaryda markazlashtiriladi.
Layerlar faqat ma’lumotni o‘zgartirmasdan uzatsa, pass-through boilerplate hosil bo‘ladi. Bitta request ko‘p mapping va allocationdan o‘tishi mumkin. Bundan tashqari feature uchun barcha layerda fayl o‘zgartirish kerak bo‘lsa, code funksional modul bo‘yicha tarqoq bo‘ladi. Layer-by-feature va vertical slice kabi variantlar shu muammoni boshqacha tashkil qiladi.
Qatlam buzilishi
Presentation controller SQL yozsa, database tafsiloti yuqori qatlamga sizadi. Data layer business qaror qabul qilsa, qoida turli repositorylarda takrorlanadi. Circular dependency qatlamlar yo‘nalishini buzadi. Static architecture test import qoidalarini tekshirishi mumkin.
DTO va domain model chegarasi ham muhim. ORM entityni to‘g‘ridan-to‘g‘ri APIga chiqarish lazy loading, maxfiy ustun va schema coupling keltirishi mumkin. Mapping xarajat bo‘lsa-da, tashqi contractni ichki modeldan ajratadi.
Deployment bilan munosabati
Layered ilova monolit artifact sifatida deploy qilinishi yoki qatlamlar fizik tierlarga ajratilishi mumkin. Business va database server orasidagi tarmoq chaqiruvi distribution xatolarini qo‘shadi. Har layerni alohida microservice qilish layer va service boundaryni aralashtiradi; service odatda vertikal biznes capabilityni qamrab oladi.
Arxitektura samarasi diagramma emas, dependency va runtime chaqiruvlari orqali tekshiriladi. Modul chegarasi, test va code review qoidalarni saqlaydi.
Bog‘liq tushunchalar
Separation of concerns, Monolithic architecture, Dependency inversion, Data access layer, Presentation layer, Clean Architecture