مهاجرت از مونولیت به ماژولار مونولیت

چطور با مهاجرت به ماژولار مونولیت - بدون دردسرهای میکروسرویس - سیستم قدیمی رو لایه‌لایه درست کنید، طوری که هر بخش به صورت واقعی مستقل بشه، اما همچنان در کنار هم یک محصول عالی داشته باشیم!

مهاجرت از مونولیت به ماژولار مونولیت

تصور کن سیستم شما مثل یه همبرگر درهم‌برهم است که همه موادش (نان، گوشت، پنیر،گوجه، سبزیجات) به هم چسبیده و جدا کردنشون غیرممکن شده! مهاجرت به ماژولار مونولیت یعنی این همبرگر خوش مزه رو به یه ساندویچ منظم تبدیل کنیم که هر لایه اش جدا ولی مرتب کنار هم قرار گرفته باشه.

Photo by Pablo Merchán Montes on Unsplash

ماژولار مونولیت چیه؟

• همه چیز در یک جعبه میمونه: برخلاف میکروسرویس‌ها که هر بخش تو یه ظرف جداگانه‌ست، اینجا همه کدها هنوز تو یک پروژه هستند، اما منظم و مرتب شده‌اند.

• قفسه‌بندی شده: سیستم به بخش‌های مستقل (ماژول) تقسیم می‌شه. مثلاً ماژول کاربران، ماژول پرداخت، ماژول گزارش‌گیری. (مثل Bounded Context در DDD)

• درها و پنجره‌های مشخص (Low Coupling): هر ماژول فقط از طریق رابط‌های واضحی با بقیه حرف می‌زنه (مثلاً APIهای داخلی و اینترفیس های مشخص).

• هر کسی آشپزی خودش (High Cohesion): هر ماژول مسئولیت کار خودش رو داره و به کار دیگران دخالت نمی‌کنه.

چرا این کار رو بکنیم؟

• کنترل آشفتگی: دیگه با یه تغییر کوچک کل سیستم بهم نمی‌ریزه!

• آماده شدن برای آینده: اگر روزی خواستید به میکروسرویس برید، کارتون راحت‌تر میشه.

مراحل مهاجرت به ماژولار مونولیت

1. ارزیابی اولیه سیستم

هدف درک وضعیت فعلی و شناسایی نقطه‌های شروع برای تفکیک ماژول‌هاست.

چطور انجام بدیم:

• تحلیل کد و دیتابیس با ابزارهایی مثل SonarQube برای شناسایی پیچیدگی‌ها.

• نقشه‌برداری سیستم با مدل C4 برای درک ساختار فعلی.

  • سطح ۱ (Context): سیستم چطور با کاربران و سیستم‌های بیرونی تعامل داره؟

  • سطح ۲ (Containers): چه کامپوننت‌هایی دارید؟ (مثلاً وب اپ، دیتابیس)

  • سطح ۳ (Components): داخل هر Container چه ماژول‌هایی وجود داره؟

• به دنبال جدول‌هایی بگردید که توسط چندین بخش از سیستم دارن استفاده میشن (مثلاً جدول Users که هم توسط ماژول احراز هویت و هم توسط ماژول گزارش‌گیری استفاده میشه).

• مثال: شناسایی ماژول‌های «مدیریت کاربر» و «سفارشات» در یک سیستم فروشگاهی.

2. تعریف مرزهای ماژول با DDD

تو این مرحله قراره سیستم رو بر اساس منطق کسب‌وکار، نه بر اساس تکنیک یا لایه‌های فنی تقسیم کنیم.

چطور انجام بدیم:

• تقسیم دامنه کسب‌وکار به زیردامنه‌ها با استفاده از اصول Domain-Driven Design.

• شناسایی زیردامنه‌ها (Subdomains):

  • دامنه اصلی کسب‌وکار را به بخش‌های کوچکتر و مستقل تقسیم کنید.

    • انواع زیردامنه:

      • Core: بخش‌های حیاتی (مثلاً تراکنش‌ها در سیستم بانکی).

      • Supporting: بخش‌های پشتیبان (مثلاً مدیریت کاربران).

      • Generic: بخش‌های عمومی (مثلاً لاگینگ).

• تعیین محدوده هر ماژول (Bounded Context):

  • هر زیردامنه تبدیل به یک ماژول مستقل میشه.

  • مرزهای ماژول‌ها باید واضح و بر اساس مسئولیت‌های کسب‌وکار باشه.

• تعریف اینترفیس‌های واضح:

  • هر ماژول باید فقط از طریق APIهای داخلی یا Eventها با بقیه ماژول‌ها ارتباط برقرار کنه.

    • از Domain Events برای ارتباط غیرمستقیم استفاده کنید.

نکته مهم این قسمت این هست که غرق مدل سازی های زیاد از حد نشیم.

3. ریفکتورینگ تدریجی با Seam Model

حالا باید بریم سراغ تکه تکه کردن سیستم قدیمی به ماژول‌های مستقل بدون ایجاد اختلال در عملکرد فعلی.

چطور انجام بدیم:

• شناسایی نقاط جداسازی (Seams):

  • Seam نقطه‌ای تو کد است که میتونیم رفتار سیستم رو بدون تغییر مستقیم کد تغییر بدیم.

  • به دنبال نقاطی بگردید که:

    • وابستگی‌های کم‌تری به بقیه بخش‌های سیستم دارند.

    • منطق کسب‌وکار مستقل و واضحی دارند.

    • امکان اضافه کردن تست‌های واحد (Unit Tests) براشون وجود داره.

• ایجاد تست‌های محافظ (Guard Tests):

  • قبل از هر تغییر، تست‌های واحد برای بخش هدف بنویسید تا مطمئن بشید رفتار سیستم بعد از تغییر حفظ میشه.

  • این تست‌ها مثل نوار ایمنی عمل میکنن تا refactoring باعث ترکیدن سیستم نشه.

• جداسازی تدریجی ماژول‌ها:

  • از الگوی Strangler Fig استفاده کنید:

    1. یک ماژول جدید برای منطق مورد نظر بسازید (مثلاً PaymentModule).

    2. به مرور متدهای مربوطه رو از مونولیت قدیم به ماژول جدید منتقل کنید.

    3. از طریق اینترفیس‌های واضح بین مونولیت قدیم و ماژول جدید ارتباط ایجاد کنید.

    4. بعد از اطمینان از صحت عملکرد، ماژول جدید رو جایگزین بخش قدیمی کنید.

4. مدیریت دیتابیس مشترک

چطور انجام بدیم:

• انتقال تدریجی با الگوی Strangler Fig:

  1. شناسایی داده‌های مرتبط با هر ماژول:

     • مثلاً برای ماژول «سفارشات»، جداول orders، order_items و payments رو در نظر بگیرید.

  2. ایجاد schemaهای جداگانه:

     • جداول مربوط به هر ماژول رو در schemaهای مجزا قرار بدید (مثلاً order_schema).

     • از ابزارهای مدیریت migrations مثل Flyway یا Liquibase استفاده کنید.

  3. انتقال تدریجی داده‌ها:

     • داده‌های جدید مستقیماً در schema جدید نوشته شوند.

     • داده‌های قدیمی به تدریج به schema جدید منتقل شوند.

  4. به‌روزرسانی سرویس‌ها:

     • سرویس‌ها به مرور به schema جدید متصل شوند.

• همگام‌سازی داده‌ها با Change Data Capture (CDC):

  • از ابزارهای CDC مثل Debezium استفاده کنید تا تغییرات داده در جدول قدیمی رو با جدول جدید sync کنید.

  • با این کار سعی می کنیم که داده‌ها در طول انتقال سینک باقی بمونن.

5. مستندسازی و نظارت

تو این مرحله میخواییم وضعیت رو حفظ و از بازگشت به وضعیت نامنظم جلوگیری کنیم.

چطور انجام بدیم:

• مستندسازی با مدل C4:

  • سطح ۱: Context Diagram

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

    • مثال: ماژول «مدیریت موجودی» چطور با ماژول «سفارشات» و «انبار» ارتباط داره.

  • سطح ۲: Container Diagram

    • اجزای اصلی سیستم (وب اپ، دیتابیس، سرویس‌ها) و ارتباطات بینشون رو بکشید.

    • مثال: نمایش دیتابیس اختصاصی ماژول مدیریت موجودی و APIهای آن.

  • سطح ۳: Component Diagram

    • جزئیات داخلی هر ماژول رو با نمودارهای دقیق‌تر توضیح بدید.

    • مثال: کلاس‌های InventoryService، StockRepository وارتباط بینشون.

  • سطح ۴: Code Diagram

    • جزئیات پیاده‌سازی رو با دیاگرام‌های UML یا توضیحات کد تکمیل کنید.

• ثبت تصمیمات با ADR (Architecture Decision Records):

  • برای هر تصمیم کلیدی (مثلاً چرا دیتابیس جداگانه برای ماژول موجودی انتخاب شد)، یک توضیح مختصر بنویسید.

• مانیتورینگ انسجام معماری با ArchUnit:

  • از این ابزار برای تعریف و اعتماد قوانین معماری استفاده کنید.

  • مثال:

    • اطمینان از اینکه ماژول مدیریت موجودی به ماژول سفارشات وابستگی مستقیم نداره.

    • بررسی اینکه تمام کلاس‌های ماژول در پکیج مربوطه قرار گرفته‌اند.

6. افزودن تست‌های خودکار

چطور انجام بدیم:

• تست‌های واحد (Unit Tests) برای هر ماژول:

  • از فریمورک‌های مختص به زبان پروژه استفاده کنید.مثل JUnit (برای جاوا)، pytest (برای پایتون) یا Jest (برای جاوااسکریپت).

  • هر ماژول باید مجموعه تست مستقل خودش رو داشته باشه.

  • روی رفتار منطق کسب‌وکار تمرکز کنید، نه روی پیاده‌سازی جزئیات.

  • مثال: تست اعتبارسنجی موجودی کالا قبل از ثبت سفارش.

• تست‌های قراردادی (Contract Tests) برای ارتباطات بین ماژول‌ها:

  • از ابزاری مثل Pact استفاده کنید تا مطمئن بشید ماژول‌ها طبق قرارداد با هم ارتباط برقرار میکنن.

  • قراردادها رو بر اساس Consumer Expectations تعریف کنید.

  • مثال: قرارداد بین ماژول «سفارشات» و ماژول «پرداخت» برای درخواست پرداخت.

• تست‌های یکپارچگی (Integration Tests):

  • تعامل بین ماژول‌ها رو در یک محیط شبیه‌سازی شده تست کنید.

  • از Docker برای ایزوله کردن محیط تست استفاده کنید.

  • مثال: تست کامل فرآیند ثبت سفارش از طریق API.

• تست‌های عملکردی (Performance Tests):

  • زیر بار واقعی، عملکرد ماژول‌ها رو بررسی کنید.

  • ابزارهایی مثل JMeter یا Gatling میتونن مفید باشن.

  • مثال: تست ریسپانس ماژول «مدیریت موجودی» برای ریکوئست های همزمان.

مسیر به سمت میکروسرویس‌ها (مختصر)

1. تقویت ماژول‌های مستقل با تست‌های کامل.

2. انتقال ماژول‌ها به سرویس‌های جداگانه با دیتابیس مستقل.

3. استفاده از Event-Driven Architecture (مانند Kafka) برای کاهش کوپلینگ.

4. مدیریت عملیاتی با ابزارهایی مانند Kubernetes.

Photo by amirali mirhashemian on Unsplash

نتیجه‌گیری

مهاجرت به ماژولار مونولیت با استفاده از DDD، Seam Model، و ابزارهایی مثل Flyway و ArchUnit، راهی کم‌ریسک برای بهبود سیستم‌های legacy است. این رویکرد میتونه زمان توسعه رو تا 30% کاهش بده و بدهی فنی رو تا 20% کم کنه، همچنین پایه‌ای برای مهاجرت کم دردسرتر به میکروسرویس‌ها ایجاد میکنه.