Modular Monolith — Cheat Sheet
🎯 يعني إيه Modular Monolith؟
تطبيق واحد
Deploy واحد
Runtime واحد
متقسم داخليًا لوحدات (Modules) مستقلة
فكّر فيه:
Microservices في الدماغ
Monolith في التنفيذ
🧩 التقسيم الصح
❌ Controllers / Services / Repositories
✅ Business Capabilities
Orders | Inventory | Billing | Users | Notifications
كل Module:
مسؤولة عن Business واحد
مالكة منطقها وداتاها
📁 Folder Structure النموذجي
Module
├─ Application (Use cases)
├─ Domain (Entities, Rules)
├─ Infrastructure (DB, Repos)
├─ API (Controllers)
└─ Module.cs (Registration)
🔒 القواعد الذهبية
❌ مفيش Module تكلم DB بتاعة غيرها
❌ مفيش Classes مشتركة عشوائي
✅ التواصل يتم من خلال API أو Events فقط
🔁 طرق التواصل
1️⃣ Synchronous (Direct Call)
Interface
Dependency Injection
In-memory
Fast
📌 استخدمه:
Core business
Reads
عمليات لازم ترجع فورًا
⚠️ عيبه:
Strong Coupling
Cascading Failures
2️⃣ Asynchronous (Messaging)
Events / Commands
Fire-and-forget
Message Contracts
📌 استخدمه:
Side Effects
Integrations
Fault Isolation
⚠️ عيبه:
Infra زيادة
تعقيد أعلى
💥 Side Effects (يعني إيه؟)
أي حاجة مش الهدف الأساسي من العملية
مثال:
إنشاء Order = الهدف
Email / Inventory / Analytics = Side Effects
✔️ تتعمل Events
❌ ما تتعملش Direct Calls
🔌 Integrations (يعني إيه؟)
التعامل مع أنظمة خارجية:
Payment
SMS
Shipping
ERP
✔️ Async
✔️ Retry
✔️ Circuit Breaker
🧱 عزل الأعطال (Fault Isolation)
Module تقع → غيرها يكمل
مفيش انتظار
مفيش Threads محبوسة
📌 يتحقق بـ:
Messaging
Events
Outbox Pattern
🧪 Arch Tests (زي NetArchTest)
اختبارات تحمي المعمارية
✔️ تمنع Module تعتمد على غيرها
✔️ تكسر الـ Build لو القاعدة اتكسرت
مثال:
Orders must NOT depend on Inventory
📦 Outbox Pattern (باختصار)
Event يتحفظ في DB
جزء من نفس Transaction
يتبعت بعد كده للـ Broker
✔️ مفيش Message Loss
🚦 إمتى تستخدم Modular Monolith؟
Team صغير/متوسط
Product لسه بينمو
عايز سرعة + تنظيم
مش عايز Infra Microservices بدري
🔮 المستقبل
لو معموله صح:
استخراج Module = سهل
التحول لـ Microservices = طبيعي
مفيش Rewrite
🥇 الجملة الذهبية
Modular Monolith مش حل مؤقت
ده Architecture ناضجة
والذكي هو اللي يبدأ بيها
Comments
Post a Comment