ءVertical Slices دقیقاً کجای Modular Monolith قرار می‌گیرند؟ 🤔

بیشتر تیم‌ها معماری در سطح کلان (macro architecture) را به‌درستی پیاده‌سازی می‌کنند. آن‌ها یک Modular Monolith با مرزهای مشخص بین ماژول‌ها، APIهای عمومی و ایزولاسیون مناسب داده‌ها می‌سازند.
اما بعد از آن، دیگر به معماری فکر نمی‌کنند! ❌

هر ماژول دقیقاً همان ساختار داخلی را دریافت می‌کند. معمولاً نوعی از Layered Architecture.

موضوع اینجاست که Clean Architecture و Vertical Slice Architecture آن‌قدرها هم که فکر می‌کنید از هم دور نیستند. هر دو روی Use Caseها تمرکز دارند و هدفشان حداکثرسازی Cohesion است.

ءClean Architecture فقط یک قانون اضافه می‌کند:
جهت وابستگی‌ها (Direction of Dependencies) باید کنترل شود. که این معمولاً منجر به Abstractionها و Ceremonyهای بیشتری می‌شود.

رویکرد Pragmatic Clean Architecture یک حد وسط را انتخاب می‌کند و از نظر ماهیت، شباهت زیادی به VSA دارد.

سوال اصلی این نیست که کدام‌یک "بهتر" است.
سوال این است که هر کدام در کجای Modular Monolith شما می‌درخشند ✨
و بخش جذاب ماجرا اینجاست:
می‌توانید آن‌ها را با هم Mix & Match کنید.

🧠 دو سطح از معماری

وقتی یک Modular Monolith می‌سازید، باید دو تصمیم معماری مهم بگیرید:

1️⃣ Macro Architecture

سیستم را چطور به ماژول‌ها تقسیم می‌کنید؟
این شامل موارد زیر است:
🔹️مرزهای ماژول‌ها
🔹️الگوهای ارتباطی بین ماژول‌ها
🔹️ایزولاسیون داده‌ها
🔹️طراحی Public API
🔹️نحوه Deploy شدن ماژول‌ها

2️⃣ Micro Architecture

کد داخل هر ماژول چطور سازماندهی می‌شود؟
این شامل موارد زیر است:
🔸️ساختار پوشه‌ها
🔸️جهت وابستگی‌ها
🔸️نحوه پیاده‌سازی Use Caseها
🔸️محل قرارگیری Validation
ُ🔸️نحوه دسترسی به دیتابیس

بیشتر مقالات درباره Modular Monolith کاملاً روی سطح Macro تمرکز می‌کنند.
و دلیل خوبی هم دارد — اشتباه گرفتن مرزهای ماژول‌ها، هزینه‌ی اصلاح بسیار بالایی دارد 💸

اما سطح Micro هم به همان اندازه مهم است.
چرا؟ چون تعیین می‌کند:
🔹️اضافه کردن Feature جدید چقدر آسان است
🔹️ءNavigation در کد چقدر ساده است
🔹️ءOnboard کردن توسعه‌دهنده جدید چقدر زمان می‌برد
این همان معماری‌ای است که تیم شما هر روز با آن تعامل دارد.

🔑 نکته کلیدی:

ءMacro Architecture مشخص می‌کند که ماژول‌ها چگونه با یکدیگر تعامل داشته باشند.
اما Micro Architecture یک تصمیم محلی است که هر ماژول می‌تواند به‌صورت مستقل بگیرد.

ماژول Ticketing شما مجبور نیست همان ساختار داخلی ماژول Notifications را دنبال کند.
مرز ماژولار این آزادی را به شما می‌دهد 🚀

ءVertical Sliceها ماژول نیستند ❗️

من دیده‌ام که بعضی‌ها Vertical Sliceها را با ماژول‌ها یکی می‌دانند.
در سطح Macro، یک ماژول می‌تواند شبیه یک "vertical slice" از دامنه‌ی کسب‌وکار به نظر برسد.
اما این تشبیه در سطح Application از بین می‌رود.

یک ماژول یک Bounded Context است.
مالک داده‌های خودش است، یک Public API ارائه می‌دهد، و یک قابلیت کسب‌وکاری را کپسوله می‌کند.

یک Vertical Slice یک الگوی پیاده‌سازی Feature است.
درخواست (Request)، Handler، Validation، و Data Access را برای یک Use Case در کنار هم گروه‌بندی می‌کند.

ماژول‌ها و Vertical Sliceها در سطوح متفاوتی عمل می‌کنند.ماژول‌ها مرزهای سیستم را تعریف می‌کنند.Vertical Sliceها کد داخل این مرزها را سازماندهی می‌کنند.

📦 ءVertical Sliceها داخل یک ماژول

ءVertical Slice Architecture کد را بر اساس Feature سازماندهی می‌کند، نه بر اساس لایه‌های فنی.

هر Feature یک واحد Self-contained است:
🔹️ءRequest، Handler، Validation، Data Access — همه در یک مکان.

🔸️در داخل یک ماژول از Modular Monolith، این یک انتخاب طبیعی است. مرز ماژول از قبل جداسازی از بقیه سیستم را اعمال می‌کند. شما به Layerها برای محافظت نیازی ندارید.Public API ماژول این کار را انجام می‌دهد.