قسمت سوم سری «مایکروسرویس و DDD برای تیم‌های کوچیک؟»

قسمت سوم سری «مایکروسرویس و DDD برای تیم‌های کوچیک؟»

✅ خواستگاه‌ و قصه‌ی شکل‌گیری مایکروسرویس (بخش ۲)


🤦🏻‍♂️ سوءبرداشت‌های پرتکرار

🔤برای سرعت، حتماً مایکروسرویس!: اگر مشکل دارید؛ شاید پاسخ مشکلتون چیز دیگه‌ای یا از جای دیگه‌ای باشه. سربارِ ارتباطات مضاعف شبکه‌ای و بین سرویسی رو در نظر بگیرید که از چاله به چاه نیوفتید. شاید Modular Monolith/Modulith با مرزبندی درست، سریع‌تر و کم‌ریسک‌تر باشه.


🔤هر جدول = یک سرویس: واحد تقسیم و شکستن سرویس‌ها «قابلیت یا کانتکست» است، نه جدول.


🔤مایکروسرویس = کوبرنتیز: کوبرنتیز ابزاره، نه توجیه. کاش وقت شه روزی خواستگاه کوبرنتیز رو هم بنویسم تا با ۳ تا سرور فیزیکی فاز «مقیاس‌پیذیری» بر نداریم! swarm و k3s و... هم هستن!


🔤سرویس کوچیک‌تر ⇒ بهتر: ریزدانه‌گیِ افراطی، انفجار هماهنگی به بار میاره!


🔤می‌خواهیم تراکنش توزیع‌شده‌ی سراسری داشته باشیم: نشونه‌ی تقسیم و شکست غلطه؛ به event-driven و... فکر کنید.


🗑بوی بدی (Smells) که نشون می‌ده راه رو کج رفتیم

- انتشار هم‌زمان چند سرویس برای یک تغییر کوچیک (Coupling پنهان).

- استفاده از Shared Database/Schema بین سرویس‌ها.

- آشفتگی ارتباطات (چند ده Call برای یک درخواست کاربر).

- استفاده سراسری از Two-Phase Commit (2PC)، بدون پذیرش event-driven/Outbox/....

- کتابخونه‌های Shared سنگین که نسخه‌بندی رو قفل می‌کنن (به‌جای قرارداد سبک).


💀 چه زمانی سراغش نرویم؟

- یک یا دو تیم کوچیک دارید و بیشترین درد شما کیفیت تست/اتوماسیون/استقراره؛ نه مرزهای دامنه.

- تغییرات کم‌بسامده و پیچیدگی دامنه متوسط.

- هنوز Observability، CI/CD، IaC در سطح پایه‌ای هم آماده نیست.

- «مالکیتِ end-to-end» برای هیچ سرویس/تیمی تعریف نشده.


در این حالت‌ها، Modulith با مرزبندی DDD (Bounded Context) «پله‌ی اول» بهتریه. هم بدهی معماری تولید نمی‌کنید، هم راهِ جداسازی آینده رو باز می‌گذارید.


🌱 نشونه‌های آمادگی :

- می‌تونید برای یک قابلیت، تیمِ مالک، بک‌لاگ، KPI و انتشار مستقل تعریف کنید.

- مولفه‌های Trace/Log/Metric شما پاسخ‌گوست: «اگر چیزی خراب شد، می‌دونید دقیقاً کجا و چرا؟»

- قراردادهایتان نسخه‌پذیره و Breaking Change رو تدریجی عرضه می‌کنید.

- داده‌ها مالک مشخص دارن و اشتراکِ مستقیمِ Schema ندارید.

- در لایه‌ی ارتباطات Fail-Fast/Retry/Timeout/Idempotency، «پروتکل تیم» است نه لطفِ داوطلبانه‌ی دولوپرها.


جمع‌بندی:

مایکروسرویس پاسخیه به استقلال تیمی، مقیاس‌پذیری ناهمگن و تحویل پیوسته در سازمان‌های بزرگ/روبه‌رشد با زیرساخت و فرهنگ آماده.

اگر این زمین بازی فراهم نباشه، نتیجه معمولاً پیچیدگی توزیع‌شده است، نه چابکی!


✍️ پی‌نوشت: اگر تا اینجا این چند پست رو دنبال کردید، امیدوارم مفید بوده باشه. اعداد نشون می‌ده که خوبه که این بحث رو اینجا متوقف کنیم. لذا پست‌های بعدی احتمالا به موضوعات دیگه‌ای اختصاص خواهد داشت.