Anti-Corruption Layer (ACL) / Adapter

فرض کنید ما در کسب و کار خودمان یا در سازمانی که کار می کنیم از معماری میکروسرویس و REST API استفاده می کنیم. ما یک سری سرویس را به صورت soap از شرکت ها یا واحدهای دیگر دریافت می کنیم.

حال سوال اینجاست که بهترین و اصولی ترین جایی که این تبدیل پروتکل باید انجام بشه کجاست؟ آیا داخل هر سرویسی که نیاز به فراخوانی سرویس soap دارد باید این کار انجام شود، داخل Api Gateway باید این تبدیل انجام شود یا جایی دیگر؟

توی این مطلب میخوام این موضوع را به صورت خیلی ساده و خودمونی و برای همیشه روشن کنم. قبل از اینکه SOAP با REST قاطی بشه و سیستم ها تبدیل به آش شله قلمکار بشن.

جواب کوتاه و محکم

بهترین و اصولی‌ترین جا برای تبدیل SOAP → REST یک لایهٔ Anti-Corruption / Adapter / Integration Layer مستقل بیرون از سرویس‌های میکروسرویسی است.

جواب کامل و مهندسی

در معماری میکروسرویس، هیچ‌وقت سرویس‌هات رو وادار نکن با دنیای عجیب SOAP صحبت کنن.

سرویس‌های تو باید فقط REST بلد باشن و فاز «من هم SOAP بلدم، هم REST، هم GraphQL، هم چایی دم می‌کنم» نگیرن.

پس باید چی کار کنیم؟

بهترین محل تبدیل پروتکل کجاست؟

1. لایه‌ی Anti-Corruption Layer (ACL) / Adapter

این همون لایه‌ایه که مثل مترجم همزمان سازمان ملل بین سرویس‌های مدرن RESTای تو و سرویس‌های باستانی SOAP طرف مقابل می‌ایسته.

این لایه:

• درخواست REST داخلی رو می‌گیره

• تبدیلش می‌کنه به SOAP

• با سرویس بیرونی حرف می‌زنه

• جواب SOAP رو تبدیل می‌کنه به JSON/REST

• و در نهایت «تمیز و اتو کشیده» تحویل میکروسرویس‌ها می‌ده

چرا اینجا بهترین گزینه‌ست؟

• جداسازی کامل پروتکل خارجی از معماری داخلی

• سرویس‌های داخلی پاک و ساده می‌مونند (Single Responsibility)

• اگر فردا SOAP منقرض شد یا REST بیرونی به gRPC تغییر کرد… فقط همین لایه رو آپدیت می‌کنی

• امکان کشینگ، لاگینگ، ریت‌لیمیتینگ، امنیت و حتی Retry logic اینجا خیلی راحت‌تره

• دیباگ و مانیتورینگ centralized می‌شه

2. گزینه‌های غلط که گاهی وسوسه‌انگیز می‌شن

• انجام تبدیل داخل خود میکروسرویس‌ها

  سرویس‌هات چاق و شلخته می‌شن، وابسته به SOAP می‌شن و SRP میره رو هوا.

• گیت‌وی، API

  گیت‌وی باید Routing و Security و throttling بکنه… تبدیل SOAP به REST؟

  عزیزم نه! اون طفل معصوم تحمل این مصیبت رو نداره.

ساختار توصیه‌شده

Internal microservices (REST)

⬇️⬆️

Integration Layer / SOAP Adapter / ACL

⬇️⬆️

External SOAP Services

ارتباط ACL با گیت وی چطور باید باشه؟

اول از همه: چه کسی با چه کسی حرف می‌زند؟

در معماری درست، جریان ارتباط این‌جوریه:

Client

⬇️

API Gateway

⬇️

Microservice (REST)

⬇️

Anti-Corruption Layer (ACL)

⬇️

External SOAP service

یعنی ACL زیرمجموعهٔ Backend است نه زیرمجموعهٔ Gateway.

چرا این ترتیب درسته؟

1. API Gateway وظیفه‌اش این‌هاست:

• احراز هویت/مجوز

• Rate Limiting

• Routing

• امنیت

• لاگ و مانیتورینگ سطح بالا

• aggregation خیلی ساده

گیت‌وی نباید تبدیل پروتکل انجام بده.

چون اگه گیت‌وی SOAP-دان بشه، دیگه بهش نمی‌گن Gateway… می‌گن «فرودگاه خدمات متفرقه!» 😅

2. ACL یک سرویس backend است، نه یک سرویس لبه (edge)

وظیفه‌اش:

• ترجمه REST → SOAP

• ترجمه SOAP → REST

• هندل کردن Retry، Error mapping، Fault mapping

• کشینگ خاص سرویس خارجی

• لاگ‌های سطح پروتکل خارجی

این کارها اساساً کار سرویس‌های داخلی است، نه Gateway.

معماری درست و تمیز (که از دور هم داد می‌زند: من حرفه‌ای‌ام)

Flow سطح کاربردی

1. کلاینت به گیت‌وی ضربه می‌زند

2. گیت‌وی درخواست را به میکروسرویس تو پاس می‌دهد

3. سرویس تو اگر نیاز داشت با سرویس خارجی حرف بزند، به ACL می‌گوید

4. ACL می‌رود SOAP را صدا می‌زند

5. پاسخ را تمیز می‌کند و REST برمی‌گرداند

6. سرویس تو جواب نهایی را می‌دهد

7. گیت‌وی آن را تحویل کلاینت می‌دهد

یک سؤال مهم:

«حالا گیت‌وی باید ACL را ببیند یا نه؟»

جواب:

نه. به هیچ‌وجه!

ACL یک سرویس داخلی است.

گیت‌وی فقط باید سرویس‌های Domain را ببیند، نه Adapterهای پشت صحنه را.

اگر گیت‌وی ACL را ببیند:

• لایهٔ دامنه دور زده می‌شود

• coupling بالا می‌رود

• ACL مجبور می‌شود رفتار API کاربر را تامین کند!! که فاجعه است.

• معماری layered رسماً می‌کشد میرود

پس معماری درست چیه؟

Gateway فقط به میکروسرویس‌ها روت می‌کند

میکروسرویس‌ها با ACL حرف می‌زنند

ACL با SOAP حرف می‌زند

یک تشبیه بامزه:

گیت‌وی مثل گارد ورودی یک شرکت است.

کارمندها (میکروسرویس‌ها) داخل ساختمان هستند.

ACL مثل مترجم شرکت است.

آیا گارد ورودی باید با مترجم وارد بحث شود؟

نه!

فقط با کارمندها حرف می‌زند.

کارمندها اگر نیاز داشتند، می‌روند سراغ مترجم. 😄

میمونه بحث احراز هویت و امنیت:

احتمالا سرویس soap نیاز به احراز هویت دارد، نام کاربری و رمز عبور اون توی چه لایه ای باید قرار بگیره؟

این سؤال دقیقاً همون نقطه‌ایه که خیلی از تیم‌ها اشتباه می‌کنن و آخرش پسورد SOAP رو میذارن تو گیت‌وی، بعد گیت‌وی دپرس میشه و شب‌ها کابوس WSDL می‌بینه 😄

روش شسته‌رفته و معماری‌شده:

نام کاربری و رمز سرویس SOAP باید در خودِ لایهٔ ACL ذخیره و استفاده شود.

نه در گیت‌وی،

نه در میکروسرویس‌های داخلی،

نه در کلاینت.

فقط و فقط ACL.

چرا باید credentialهای SOAP در ACL باشند؟

1. ACL تنها لایه‌ای است که مستقیماً با SOAP سرویس خارجی حرف می‌زند

پس طبیعیه که احراز هویت مخصوص SOAP هم همین‌جا انجام بشه.

میکروسرویس‌های داخلی نباید حتی بوی SOAP بهشون بخوره.

2. جداسازی مسئولیت‌ها (SRP)

• گیت‌وی = احراز هویت کاربران سیستم شما

• میکروسرویس = منطق دامنه

• ACL = ترجمه پروتکل + امنیت سرویس‌های خارجی

اگر پسورد SOAP رو جای دیگه بذاری، این مرزهای طلایی قاطی میشه.

3. امنیت

اگر credentialهای SOAP وارد گیت‌وی شوند:

• گیت‌وی عملاً تبدیل می‌شود به سرویس خارجی شما

• attack surface بیشتر می‌شود

• مدیریت Rotation سخت می‌شود

• لاگ‌ها خطرناک می‌شوند

اما اگر فقط ACL آنها را بداند،

امنیت و مدیریت ساده و متمرکز می‌ماند.

بهترین مکان ذخیره credentials دقیقا کجاست؟

داخل ACL، ولی در این ساختار:

• ذخیره در Secret Manager (مثل Vault, AWS Secrets Manager, Kubernetes Secrets)

• Inject شدن در ACL هنگام startup

• استفاده فقط در کد adapter

• عدم ذخیره سازی مستقیم در config معمولی یا image

چه چیزی هرگز نباید اتفاق بیفتد؟

• گیت‌وی credential SOAP را پاس بدهد

• کلاینت credential SOAP را بداند

• درخواست REST داخلی شامل یوزر/پسورد SOAP باشد

• سرویس داخلی خودش credential را ذخیره کند

پیشنهاد بهتر: Token Relay + Rotation

اگر سرویس SOAP امکان استفاده از token داشته باشد (بعضی WSDLها دارند)،

بهترین کار:

• ACL در startup یا دوره‌ای token بگیرد

• token را در حافظه یا cache امن نگه دارد

• برای هر درخواست از همان token استفاده کند

این کار امنیت را چند برابر بالا می‌برد.