Anti-Corruption Layer

Anti-Corruption Layer — bir tizimning domain modeli va tili boshqa tizimning modeli, API’si yoki legacy tuzilmasi tomonidan buzilmasligi uchun ular orasida qo‘yiladigan himoya va tarjima qatlami. Bu yondashuv Domain-Driven Design’da bounded contextlar o‘rtasidagi integratsiyani boshqaradi.

Qatlam tashqi tizimning concept, field, error va workflow’larini ichki domain tiliga moslashtiradi.

Muammo

Legacy tizimda customer quyidagicha bo‘lishi mumkin:

CUST_NO
CUST_STAT
BALANCE_TYPE

Yangi tizim esa:

CustomerId
CustomerStatus
CreditBalance

tushunchalaridan foydalanadi.

Tashqi nom va qoidalarni domain ichiga to‘g‘ridan-to‘g‘ri olib kirish modelni ifloslantiradi.

Bounded context

Har bounded context o‘z model va ubiquitous language’iga ega.

Bir contextdagi Order boshqa contextdagi Order bilan aynan bir ma’noda bo‘lmasligi mumkin.

Anti-Corruption Layer ular orasidagi semantik farqni explicit tarjima qiladi.

Adapter

Qatlam tashqi API yoki SDK’ni ichki interface’ga moslashtiruvchi adapterlardan foydalanadi.

Masalan:

LegacyCustomerGateway
→ CustomerRepository interface

Domain service tashqi protocol va field nomlarini bilmaydi.

Translator

Translator tashqi DTO’ni ichki entity yoki value objectga aylantiradi.

field mapping;
enum conversion;
unit conversion;
timezone;
null;
default;
validation

bilan ishlaydi.

Reverse translator ichki commandni tashqi request formatiga aylantiradi.

Facade

Tashqi subsystem murakkab bo‘lsa facade bir nechta endpoint yoki service’ni bitta aniq operationga birlashtiradi.

Masalan, customer yaratish uchun legacy tizimda uchta API chaqirilishi mumkin.

Ichki domain esa register_customer() kabi bitta contract ko‘radi.

Tashqi DTO

External response domain entity sifatida ishlatilmaydi.

U alohida DTO bo‘lib qoladi.

Bu tashqi provider field qo‘shsa yoki nomini o‘zgartirsa domain modelga bevosita ta’sirni kamaytiradi.

Domain modelni himoyalash

Anti-Corruption Layer tashqi modelning quyidagi elementlarini ichkariga o‘tkazmaydi:

noma’lum status kodlari;
texnik ID formatlari;
legacy null qoidalari;
tashqi exception;
API pagination;
transport metadata.

Ichki qatlam domain ma’noli type va errorlar bilan ishlaydi.

Error mapping

Tashqi xatolar domain xatolariga aylantiriladi.

Masalan:

HTTP 409 → CustomerAlreadyExists
HTTP 429 → ExternalRateLimited
timeout → ExternalServiceUnavailable

Tashqi raw error logda saqlanishi mumkin, lekin clientga domain contract qaytariladi.

Semantik farq

Faqat field nomlarini almashtirish yetarli bo‘lmasligi mumkin.

Masalan, tashqi tizimdagi active status ichki tizimda:

verified;
not blocked;
subscription valid

shartlari kombinatsiyasiga teng bo‘lishi mumkin.

Translator business semantikani aniq ifodalaydi.

Data ownership

Qaysi tizim qaysi ma’lumot uchun source of truth ekani belgilanadi.

Anti-Corruption Layer:

faqat read;
command yuborish;
synchronization;
cache;
local projection

modelidan birini ishlatadi.

Ikki tizim bir fieldni mustaqil boshqarsa conflict paydo bo‘ladi.

Synchronous integration

Ichki operation tashqi tizimga darhol request yuboradi.

Afzalligi — natija tez ma’lum.

Kamchiligi:

latency;
timeout;
availability dependency;
retry;
distributed transaction muammosi.

Circuit breaker va timeout qatlam ichida boshqarilishi mumkin.

Asynchronous integration

Tashqi eventlar queue orqali keladi.

Qatlam eventni ichki domain event yoki projectionga aylantiradi.

Bu availability couplingni kamaytiradi.

Evaziga eventual consistency, ordering va duplicate delivery paydo bo‘ladi.

Legacy migration

Yangi tizim legacy database yoki service bilan bir muddat parallel ishlashi mumkin.

Anti-Corruption Layer migration davomida:

read redirect;
dual read;
data mapping;
compatibility;
incremental replacement

vazifasini bajaradi.

Legacy olib tashlangach qatlam qisqarishi yoki o‘chirilishi mumkin.

Tashqi model evolyutsiyasi

Provider API yangi version chiqarsa mapping alohida adapterda yangilanadi.

Domain code eski va yangi provider detallarini bilmaydi.

Versionlar parallel ishlasa:

ProviderV1Adapter
ProviderV2Adapter

yaratilishi mumkin.

Test

Testlar:

field mapping;
enum;
precision;
timezone;
missing field;
tashqi xato;
retry;
idempotency;
eski va yangi API version

holatlarini qamrab oladi.

Contract test real provider sandboxi bilan bajarilishi mumkin.

Logging

Qatlam tashqi request va ichki correlation IDni bog‘laydi.

Logda:

provider;
operation;
duration;
status;
retry;
mapping version

ko‘rsatiladi.

Secret va personal payloadlar redaction qilinadi.

Kamchiliklari

Qo‘shimcha class va mapping kodi talab qiladi.

Tashqi tizimning barcha imkoniyatini ichki contractga moslashtirish qiyin bo‘lishi mumkin.

Noto‘g‘ri abstraction tashqi semantik farqni yashirib, xato business qaroriga olib keladi.

Canonical model

Bir nechta tashqi tizim bilan integratsiyada ichki canonical DTO ishlatilishi mumkin.

Har provider o‘z formatidan canonical modelga map qilinadi.

Canonical model barcha provider fieldlarini bitta ulkan optional structure’ga aylantirmasligi kerak.

Domain uchun haqiqatan umumiy tushunchalar saqlanadi.

Mapping ownership

Mapping qoidalarining egasi belgilanadi.

Tashqi provider field ma’nosini o‘zgartirsa adapter jamoasi yangilaydi.

Business semantika o‘zgarsa domain jamoasi contractni qayta ko‘rib chiqadi.

Noaniq ownership yashirin data xatosini uzoq vaqt saqlashi mumkin.

Performance

Qatlam qo‘shimcha network hop bo‘lsa latency oshadi.

Ba’zan u application ichidagi library sifatida ishlaydi, ba’zan alohida service.

Alohida service faqat mustaqil scale, security yoki ko‘p consumerga umumiy tarjima zarur bo‘lsa asosli.

Cache

Tashqi tizim sekin bo‘lsa qatlam lokal projection yoki cache saqlashi mumkin.

Cache source of truth emas.

Freshness, invalidation va providerdagi delete hodisasi aniq boshqariladi.

Bog‘liq tushunchalar

Domain-Driven Design, Bounded context, Adapter Pattern, Facade, Translator, Legacy system, Domain model, Ubiquitous language, Integration layer