🍰🚀 معماری Vertical Slice

🍰🚀 معماری Vertical Slice

مقدمه

طراحی معماری نرم­‌افزار همیشه تلاشی بوده برای اینکه پیچیدگی‌ها رو مهار، تغییرات رو ساده، و تیم رو چابک نگه داره. چندین ساله که در گفتگوها Clean Architecture رو زیاد می‌شنویم و گویی که لازمه داشتن یک معماری خوب اینه که اول clean رو پیاده کنیم، بعد به سایر جنبه‌ها فکر کنیم!! طی «حداقل» این پست، مقایسه‌ای خواهیم داشت بین معماری vertical slice و clean، و بعد تفاوت‌ها و شباهت‌ها، مزایا و معایب، و در نهایت سناریوهای انتخاب رو مرور خواهیم کرد.

فبل از شروع دو تا مفهوم رو مرور کنیم:

- وابستگی یا Coupling:

میزان وابستگی بخش‌های مختلف سیستم به همدیگه. tight coupling یعنی تغییر یک بخش، می‌تونه بخش دیگه‌ای رو خراب کنه. loose coupling اجازه می‌ده بخش‌های مختلف سیستم، مستقلا تکامل و تغییر داشته باشن

.

- همبستگی یا Cohesion:

تناسب و یکدستی عناصر داخل یک ماژول. high cohesion یعنی همهٔ اجزای ماژول یک هدف روشن دارند و چون یک هدف رو دنبال می‌کنن درکشون ساده‌تره؛ low cohesion یعنی کدهای بی‌ربط کنار هم‌ قرار گرفتن.

خلاصه‌ اینکه Coupling → «چقدر به هم وابسته‌ایم؟»

و Cohesion → «چقدر به هم متعلقیم؟»

ایده اصلی clean architecture رو uncle bob معروف سال ۲۰۱۲ طرح کرد، اونم با هدف اینکه جهت وابستگی باید همیشه به سمت «درون» باشه و درونی‌ترین لایه هم که domain است، ولی این صورت ماجراست، هدف اصلی‌ کاهش وابستگی‌ها (control/loose coupling) بود. گاهی (که بعدن توضیح می‌دم کجا) پَرش بین پوشه‌ها و کدهای مختلف زیاد و دشوار می‌شه؛ چرا؟ چون تقسیم‌بندی و جداسازی کدها براساس ماهیت تکنیکال اون‌ها انجام شده، مثلا همه سرویس‌ها زیر پوشه سرویس‌ها، همه کامندها زیر پوشه کامندها و...

حالا vertical slice تقسیم‌بندی رو بر اساس use caseها یا featureها انجام می‌ده، یعنی همه مفاهیم تکنیکال مرتبط با یک feature (قابلیت) کنار هم قرار خواهند گرفت. اینجوری cohison بالاتر و complexity کمتر خواهد شد و مدیریت راحت‌تر خواهد بود. مثل یک قطعه از کیک که تمام لایه‌ها رو با هم داره 🍰

معماری Vertical Slice رو Jimmy Bogard سال ۲۰۱۸ در کنفرانس NDC سیدنی معرفی رسمی کرد با اینکه ایده اولیه‌اش رو از ۲۰۱۵ مطرح می‌کرد. شاید بد نباشه بدونید Jimmy Bogard خالق AutoMapper, MediatR و Respawn است.

مقایسه ساختاری:

Clean Architecture Sample:

┬ src

├── Domain

│ └── Entities/

├── Application

│ └── UseCases/

├── Infrastructure

│ └── Persistence/

└── WebApi

└── Controllers/

Vertical Slice Architecture Sample:

┬ src

├── Orders

│ ├── Create

│ │ ├── Command.cs

│ │ ├── Handler.cs

│ │ ├── Validator.cs

│ │ └── Tests/

│ └── Cancel/...

└── Shared/...

وقتی کد بزرگه، تیم‌های متعدد درگیر یک پروژه می‌شن و سرعت تحویل قابلیت‌ها باید بالا باشه، تفاوت بین این دو تا پررنگ می‌شه. برای تیم‌ و پروژه کوچک عموما در سطح «ادا» است تفاوت‌ها 😁 ولی بسته به ساختار و رویه‌های داخل تیم، توی پروژه‌های بزرگ و خیلی بزرگ؛ انتخاب نابجای هر کدوم می‌تونه دشواری نگهداری و توسعه محصول رو دستخوش تغییر بزرگ کنه.

💬 نظر و تجربه شما چیه؟ دوست دارید روی این موضوع عمیق‌تر شیم؟