🎮 تاریخچه زمینه پیدایش Clean / Hexagonal / Onion

🎮 تاریخچه زمینه پیدایش Clean / Hexagonal / Onion

در یک نگاه، سه الگوی «clean»، «hexagonal» و «onion» همه با یک هدف مشترک متولد شده‌اند: جدا کردن «منطق دامنه» از جزئیات متغیّر فناوری (UI، دیتابیس، فریم‌ورک‌ها) و معکوس کردن جهت وابستگی‌ها. تفاوت‌شون در زاویه دید و لایه‌بندی است؛ hexagonal روی ports و adapters (درگاه‌ها و آداپترها) تأکید می‌کنه، و onion روی «وابستگیِ رو به هسته» و clean یک معماری‌ ترکیبیه که ایده‌های هر دو رو با تمرکز روی use-case گسترش می‌ده.

اما درست مثل مایکروسرویس و DDD، پیاده‌سازی زودهنگام یا بدون مسئله واقعی، می‌تونه هزینه و پیچیدگی بی‌فایده تحمیل کنه.

📇 ریشه و سیر تکامل

- هگزاگونال (Ports & Adapters)

سال ۲۰۰۵ توسط Alistair Cockburn مطرح شد؛ هدف: «قابلیت تست مستقل از UI و پایگاه داده و جلوگیری از بلاک شدن توسط فناوری»

عملا core system از طریق «پورت»‌ها با جهان بیرونی‌اش صحبت می‌کنه؛ هر پورت می‌تونه آداپترهای مختلف مثل REST، CLI، تست و... داشته باشه.

🧅 معماری onion

توسط Jeffrey Palermo در سال ۲۰۰۸ معرفی شد؛ قانون طلایی: «تمام وابستگی‌ها باید به سمت مرکز (دامین مدل) باشن»

چهار رکن اصلی به گفتهٔ خودش:

۱: سیستم باید حول یک object model مستقل شکل بگیره

۲: لایه‌های داخلی interfaceها رو تعریف می‌کنن و لایه‌های بیرونی interfaceها رو پیاده‌سازی.

۳: جهت اتصال به سمت مرکزه.

۴: امکان کامپایلِ Core بدون زیرساخت باید محقق بشه.

معماری clean

توسط پیرمرد پرحاشیه‌ی این روزها 😅 رابرت سی. مارتین (uncle bob) مفهوم «Clean Architecture» سال ۲۰۰۸ توی وبلاگش شرح داد؛ معماری‌ای لایه‌ای با entityها، use caseها و interface adapter که «مستقل از فریم‌ورک و قابل تست» باقی بمونن.

معماری clean رو می‌شه ترکیبی تکامل‌یافته از hexagonal و onion دونست که حلقه‌های بیشتری (Entities, Use-Cases, Interface Adapters…) تعریف می‌کنه.

⚖️ چه‌وقت‌ مناسبند؟

- وقتی پیچیدگی دامنه واقعاً بالاست؛ قوانین در حال تغییر و تعاملات متعدد دارید.

- طول عمر سیستم طولانیه و انتظار تغییر فناوری‌های UI یا دیتابیس یا کلن لایه‌های فنی را داریم.

- نیاز به یونیت‌تست قبل از آماده بودن زیرساخت احساس می‌شه.

🧩 نسبتشون با DDD و مایکروسرویس

این الگوها «دامین‌سنتر» هستند، اما استفاده ازشون الزاماً به معنی DDD نیست؛ همون‌طور که DDD بدون این معماری‌ها هم ممکنه.

در معماری مایکروسرویس، به‌کارگیری یکی از این الگوها برای هر سرویس به استقلال توسعه/دیپلوی کمک می‌کنه، ولی اگر مقیاس تیم یا ماژول کوچک باشه، شاید حتی الگوی ساده لایه‌ای کفایت کنه! — مثل همون اشتباه «پیاده‌سازی زودهنگام مایکروسرویس».

💬 تجربه شما؟