💡 آیا مایکروسرویس و DDD برای تیم‌های کوچک مناسبه؟

از اونجایی که تعداد تیم‌هایی که تلاش کردن/می‌کنن تا DDD رو پیاده‌سازی کنن و یا محصول مبتنی بر معماری مایکروسرویس توسعه بدن، ولی در میانه‌ی راه متوجه دشواری‌ها، مشکلات و یا اشتباهات متعدد طراحی و پیاده‌سازی می‌شن، کم نیست؛ خوبه تا پرسش رو مرور کنیم، تا اگر موضوع مورد اقبالی بود بیشتر در موردش گپ بزنیم.

❓ ریشه و خواستگاه این طراحی و معماری کجاست؟
تا حالا به خواستگاه و پیشینه‌ی خالقین DDD یا Microservice توجه داشتید؟ منظورم «خواستگاه نیازهایی» است که به خاطر برطرف شدن اون نیازها، افرادی با «پیشینه و تجربه‌ی مشخص در تعامل با نوع خاصی از مسائل و سازمان‌ها» شروع به طراحی راهکار یا پاسخ برای اون نیازها در اون سازمان‌ها کردن؛ و بعدتر این راهکارها در سازمان‌هایی با چه مختصات و ابعادی، توسط چه افرادی توسعه و تکامل پیدا کرد تا امروز به انضمام این تعداد کتاب و مقاله و ویدیو و کنفرانس، در اختیار ما باشه؟!

بیاید با هم چند تا سوال کاریکاتوریزه رو مرور کنیم:

۱: از نظر امکانات در دسترس: آیا یک پزشک حاذق که تمام عمرش در پیشرفته‌ترین بیمارستان‌های ژاپن یا سوییس تحصیل و کسب‌تجربه کرده؛ به صورت مستقیم (و طبیعتا بدون تغییر و سازگارپذیری) می‌تونه بره در یکی از مناطق محروم اتیوپی شروع به درمان کنه؟

۲: از نظر مقیاس‌ها: آیا مرسومه که از ابزارآلات تعمیر ماشین‌های معدن در کارگاه ساعت‌سازی استفاده کنن یا برعکس؟

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

🔑 چاره کار چیه؟
» اگر دنبال یک مسیر قابل تعمیم به عام باشیم، راه رو به خطا رفتیم؛ عملا عیار یک architect یا software engineer سنیور یا بالاتر (بسته به سایز سازمان و محصول) در میزان موفقیت و ظرافت‌های طراحی مسیر، راهکار و معماری مشخص می‌شه. قرار هم نبوده و نیست، همه یک میزان موفقیت کسب کنن. خیلی‌ها هم شکست میخورن یا پیروزی‌نمایی می‌کنن.

➖اگر دوست داشتید این بحث ادامه پیدا کنه لطفا با ⚙️ اعلام کنید تا در اگر به حدنصاب رسید ادامه بدیم..
(موضوعاتی مثل Strategic DDD یا Modular Monolith/Modulith، شناسایی پیش‌نیازها، فازبندی تغییرات و پیاده‌سازی، امکان‌پذیری transformation و... می‌تونن محور این سری از مطالب باشن)


🗽 سخن بزرگان:

👨🏼‍🦳 مارتین فالر: توی مقاله معروف "Microservice Prerequisites" سه تا پیش‌نیاز اساسی رو مطرح می‌کند:

قابلیت Rapid provisioning: قابلیت راه‌اندازی سریع infrastructure
قابلیت Basic monitoring: نظارت و observability
قابلیت Rapid application deployment: استقرار سریع نرم‌افزار
«در صورت ادامه بحث، چند مورد دیگه رو هم من بنا به تجربه اضافه خواهم کرد»

👨🏼‍🦳 کریس ریچاردسون توی کتاب "Microservices Patterns" بحث pattern-based approach رو ارائه می‌کنه وبارها تأکید داره مایکروسرویس «نسخه‌ی واحد برای همه» نیست و باید دید کِی و چرا سراغش بریم؛ حتی «دلایل نادرست برای پذیرش مایکروسرویس» رو هم مستند کرده.

👨🏼‍🦳 استفان تیلکوف توی مقاله «Don’t start with a monolith» می‌گه وقتی هدف نهایی شما معماریِ مایکروسرویس باشه (به‌ویژه برای سیستم‌های بزرگ)، «شروع با مونولیت» غالباً انتخاب درستی نیست و باید از اول به مرزبندی‌های سخت‌گیرانه و سیستم‌های مستقل فکر کرد. بعدتر تیلکوف الگوی Self-Contained Systems (SCS) رو هم به‌عنوان رویکرد هم‌خانواده و کم‌اصطکاک‌تر معرفی می‌کنه. ۴ سال بعدش، سم نیومن میاد روی روش‌ها و الگوهای تکاملی برای شکستن مونولیت تمرکز می‌کنه (نه نفی یا اثبات مطلق هر کدوم)، و راهکارهای عملی برای مهاجرت تدریجی ارائه می‌ده. کتاب معروف نیومن یعنی "Monolith to Microservices" عملاً پاسخ عملیِ «چگونه از مونولیت به مایکروسرویس برسیم؟» حساب می‌شه (اینو گفتم که بگم بین علما و بزرگان هم تفاوت نظر وجود داره 😁 خصوصا در مورد فالر و ریچاردسون؛ چون فالر استراتژی «اول مونولیت» برای شروع کارهای جدید رو طرح می‌کنه و می‌گه با این نکته که حتی اگه بعداً احتمالاً به مایکروسرویس برسید! این دیدگاه روبه‌روی موضع تیلکوف قرار می‌گیره و نشون می‌ده اختلاف‌نظر معنادار بین علما جدیه! )