عموما انتخاب معماری، تکنولوژی یا ابزار، از بین ابزارهای موجود و شناخته‌شده انجام می‌شه و به ندرت تیم‌ها نیاز یا حتی توانایی خلق معماری جدید رو دارن. توی چنین شرایطی شناخت معماری و زمینه‌ی پیدایشش کمک بزرگی به پیشگیری از انتخاب اشتباه می‌کنه. یعنی وقتی می‌دونیم یک معماری در چه شرایطی و برای تأمین چه نیازی به وجود اومده، می‌تونیم فکر کنیم آیا شرایط و نیاز و مسئله‌ی فعلی ما هم راستا با شرایط و نیاز ما هست یا نه!

قصد دارم تا طی چند پست در مورد چند معماری مرسوم که عموما به اشتباه انتخاب می‌شن و بیشتر از اینکه انتخابشون تابعی از نیاز و شرایط باشه، ناشی از ترندهای فضای نرم‌افزار و حباب‌هاست بپردازم...

- مایکروسرویس
- متدولوژی Domain-Driven Design
- معماری‌ها Clean / Hexagonal / Onion

اگر فکر می‌کنید موضوع جذابیه: ⚙️
اگر هم پیشنهادی براش دارید حتمن بنویسید 😊

📇 تاریخچه و زمینه پیدایش مایکروسرویس

شاید بد نباشه تا دفعه بعد که خواستید در مورد معماری و ساختار یه پروژه تصمیم بگیرید، یه بار پیشینه‌ی پیدایش مایکروسرویس رو مرور کنین تا از تناسب «نیاز» و «راهکار»ی که مدنظر دارید مطمئن باشید.

نمیشه دقیق و قاطع گفت «اولین» بار کی مفهوم مایکروسرویس رو پیاده کرده. مفهوم مایکروسرویس‌ از تکامل معماری‌های قبل‌تر از خودش، خصوصا به عنوان یک پاسخ به محدودیت‌های سیستم‌های یکپارچه، و پیچیدگی معماری سرویس‌گرا (SOA) شکل گرفت. حالا دو چیز رو باید توضیح داد، یک شیوه‌های امروزی‌تر پیاده‌سازی مایکروسرویس، و یکی مفهوم و معماری‌اش. برای پیاده‌سازی مدرن، نتفلیکس رو می‌شه به عنوان یکی از اولین و تأثیرگذارترین پذیرندگان رویکرد میکروسرویس‌ توی مقیاس بزرگ شناخت. نتفلیکس مهاجرت خودش از معماری یکپارچه به مایکروسرویس‌ها رو حدود سال ۲۰۰۹ شروع کرد، خیلی قبل از اینکه اصطلاح "مایکروسرویس‌" به طور رسمی سال ۲۰۱۱ مطرح بشه. تا سال ۲۰۱۱، نتفلیکس طراحی مجدد بخش قابل توجهی از سیستم‌هاش به مایکروسرویس‌ها رو تکمیل کرده بود و از AWS استفاده می‌کرد، و خیلی از الگوهایی که امروز به عنوان استاندارد یا best practice شناخته می‌شن رو پیاده کرده بود.

ولی از نظر مفهومی، آمازون یکی از پذیرندگان اولیه و کلیدی است. یعنی حدود سال ۲۰۰۱، آمازون (در اون زمان تحت هدایت جف‌ بزوس) شروع می‌کنه به تجزیه سیستم‌های یکپارچه، بزرگ و مستحکمش به سرویس‌های کوچک‌تر و مستقل تا بتونه مشکلات مقیاس‌پذیری و استقرار رو بهبود بده. این انتقال، زمینه رو برای اونچه سال‌ها بعد، به عنوان معماری مایکروسرویس می‌شناسیم، فراهم کرد.

پذیرندگان بعدی این معماری، از eBay و Spotify و... همه یک سری دغدغه مشترک داشتن، یعنی مقیاس‌پذیری، پیچیدگی و وسعت سیستم، و استقرار، اونم با تیم‌های بزرگ.

بیایم نگاه بندازیم به روایات!
جناب Fred George یکی از پیشگامان معماری مایکروسرویس می‌گه هر مایکروسرویس باید به قدری ساده و کوچک باشه که توی ذهن یک توسعه‌دهنده جا بشه:

"small enough and simple enough that a single developer can understand the whole thing"

بعدتر همین رو مارتین فولر هم به نحوی تکرار می‌کنه.

حالا سوال اینه که اگر تیم توسعه و تعداد سرویس‌ها بزرگ نیستند، آیا مقیاس‌پذیری مورد نیازمون به حدی رسیده که scale-up پاسخگو نباشه و بریم سراغ شکست و توزیع سرویس‌ها؟ آیا زیرساخت لازم رو از پردازش ابری تا DevOps تا مونیتورینگ/observabilty و... داریم؟ آیا ظرفیت مستندسازی API، فرایند، کاتالوگ داده‌ها و فرایندها و... رو داریم؟

تجربیات مستند زیادی وجود داره که استارتاپ‌ها و تیم‌های کوچیک زیادی «زودتر از موعد» به سراغ مایکروسرویس رفتن و از عهده‌ی سربارش بر نیومدن... یادمون نره، معماری باید در خدمت مسائل ما باشن، نه اینکه ما در خدمت معماری دربیایم.

توی مباحث DDD به تفصیل خواهم گفت که معماری سازمانی ما هم حتی باید با شیوه تحلیل نیازمندی‌ها و شیوه ترجمه‌ی اون‌ها به راهکارهای نرم‌افزاری سازگار باشه.

مایکروسرویس فقط تفیکیک کدها به چند پوشه و وصل کردنشون با API و دپلوی کردنشون تحت پروسه‌های مجزا نیست! و ای بسا می‌تونه آغازی بشه بر مصیبت‌های آشکار فنی و آسیب‌های پرشمار پنهان، منجمله نپرداختن به ریشه‌ی کاستی‌ها، یا افتادن به تله‌ی مرزبندی اشتباه سرویس‌ها از هم.

لذا مایکروسرویس، در زمان مناسبش و با فراهم کرن پیش‌نیازهاش، و علی‌الخصوص وقتی که در خدمت حل‌کردن مسائل ما باشه همون قدر خوب و مفیده که وقتی زودهنگام یا بدون پیش‌نیازهاش می‌ریم سراغش، مضر!

💬 نظر یا تجربه شما چیه؟

🔭 تاریخچه و زمینه پیدایش Domain-Driven Design

اوایل دههٔ ۲۰۰۰ شرکت‌های خیلی بزرگ (بانک‌ها، بیمه، و …) با سیستم‌های نرم‌افزاری‌ای روبه‌رو بودند که:

- دامین‌های با پیچیدگی خیلی بالا داشتند (مثل قوانین کسب‌وکار پرشمار و در حال تغییر).

- گپ ارتباطی وحشتناکی بین تحلیلگرها و برنامه‌نویس‌ها وجود داشت؛ اصطلاحات یکی برای دیگری نامفهوم بود.

- هر تغییر کوچک به موجی از regression bugها و استرس انتشار تبدیل می‌شد.

توی چنین شرایطی، Eric Evans می‌گه: «بیایید به جای تمرکز صِرفن روی لایه‌های فنی، قلب مسأله—یعنی دامنه—رو محور کار بگذاریم.» نتیجه شد متدولوژی Domain-Driven Design که توی کتاب معروف «آبی» در سال ۲۰۰۳ متولد شد و ‌بعدتر با کارهای Vaughn Vernon، Jimmy Nilsson و بقیه گسترش پیدا کرد.

برخی مفاهیم پایه در DDD:

- مفهوم Ubiquitous Language
زبان مشترک بین همهٔ ذی‌نفعان. کلاس، جدول DB و اسلاید ارائه باید از یک واژه برای یک مفهوم استفاده کنند، و یک واژه باید همه جا معنی یکسان داشته باشه.

- مفهوم Bounded Context
مرزهایی شفاف برای معنی واژه‌ها. «سفارش» در حسابداری ≠ «سفارش» در انبار.

- مفهوم Aggregate
یک خوشه (گروه) از آبجکت‌ها، با یک ریشهٔ واحد که می‌شه به‌صورت واحد تلقی کردشون.

- مفهوم Context Map
نقشهٔ روابط بین Bounded Contextها؛ شامل پیوندهای همکار، مشتری–تأمین‌کننده و…

- مفهوم Strategic Design
هنر تشخیص اینکه کِی باید دامنه رو بشکنیم و تیم رو حولش سازمان‌دهی کنیم.

آیا DDD برای همه است؟ نه دقیقاً!
توی «مطلب قبل» دربارهٔ وسوسهٔ ترندها گفتم، DDD هم قربانی حباب‌ها شده. نشونه‌های انتخاب اشتباه:

- دامنه ساده است (CRUD سرراست، منطق پیچیده‌ای هم نداره) ولی تیم حتماً می‌خواد Bounded Context تعریف کنه و Event Storming برگزار کنه!

- ابزارهای تحلیلی، تست، مستندسازی و DevOps هنوز بالغ نیستند اما «می‌خواهیم معماری تمیز + DDD + مایکروسرویس» رو با هم پیاده کنیم.

- تیم کوچک است ولی هر کانتکست رو توی یک ریپو جداگانه Deploy می‌کنه و نصف زمانش صرف هماهنگی بین ریپوها می‌شه.

یادمون نره: DDD هزینه داره—هم آموزشی، هم طراحی، هم نگهداری.
اگر درد پیچیدگی دامنه رو حس نمی‌کنیم، این دارو تلخ و بی‌فایده است!!

چرا لزوماً هر معماری دامین-سنتریک، DDD نیست؟!
— بعدتر دراین‌باره خواهم نوشت که هر گردی گردو نیست!! پیاده‌سازی Clean / Hexagonal / Onion به معنی DDD نیست!

«توی DDD، معماری کد فقط یک لایه از ماجراست؛ موفقیت زمانی رقم می‌خوره که ساختار سازمانی و فرایندهای تیم هم با مرزهای دامنه منطبق شن. اگر تیم کوچکه و دامنه پیچیدگی بالایی نداره، صرف داشتن لایهٔ Domain یا استفاده از معماری Clean، شما صاحب DDD نمی‌شید.»

🔔 اگر علاقه‌مند بودید، روز ۴ خرداد (۲۵ می) ساعت ۱۹:۳۰ به وقت تهران جلسه‌ای به همت انجمن DDD ایران برگزار می‌شه که اگر عمر و فرصتی بود، در این مورد به تفصیل صحبت خواهم کرد. اطلاعات ایونت رو توی کامنت قرار خواهم داد.

💬 نظر؟ تجربه؟

💡آیا ویندوز NT واقعا سیستم‌عامل پیشرفته‌ای بود؟ نمونه مقایسه مهندسی، به جای هیجانات شخصی...

امروز داشتم بوکمارک‌‌تکونی می‌کردم، یهو پست وبلاگ Julio Merino که ماه‌ها پیش ذخیره کرده بودم تا در موردش بنویسم و فراموش کرده بودم رو دیدم.

آقای Julio Merino پیشتر در گوگل و مایکروسافت و الان هم در snowflake مشغول به کاره و روی سیستم‌های یونیکس‌بیس خیلی مسلطه (معماری و لایه‌های پایین‌تر سیستم عامل) و جز دولوپرهای FreeBSD و NetBSD بوده. توی این پست توضیح می‌ده که آیا تعریف و تمجیدهایی که از پیشرفته بودن سیستم‌عامل Windows NT در سال ۱۹۹۳ می‌شده در مقابل یونیکس‌سانان مثل BSD درست بوده یا نه؟!

شاید ما هرگز سیستم عامل توسعه ندیم یا تا لایه‌های خیلی پایین کرنل عمیق نشیم؛ ولی خوبه بدونیم مقایسه صحیح دو تا سیستم ولو اینکه به ۳۰ سال پیش برگردن، آداب و روشی داره که توی این مقاله به خوبی یاد می‌ده...

مقاله مفصلیه، و از حوصله پست تلگرامی خارج. ولی مثلا از hybrid microkernel یا Async I/O میگه که NT جلوتر از زمان خودش و پیشرفته از Unix بوده و بعد نظرش رو توضیح می‌ده که چطور linux و یونیکس‌سانان این سال‌ها گپ‌ها رو پر کردن و چالش‌های اصلی توسعه ویندوز چیاست از نظرش.

هدفم از اشتراک این مطلب اینه چقدر در بین مقایسه‌هایی که در مورد زبان‌ها، تکنولوژی‌ها، معماری‌ها و... می‌بینیم، روش و معیارهای فنی می‌بینیم، و چقدر بر اساس رسانه و هیجان و تصورات ذهنی‌مون قضاوت می‌کنیم...