تمام فایل‌ها برای یک مورد استفاده واحد، در داخل یک پوشه گروه‌بندی می‌شوند. بنابراین، انسجام برای یک مورد استفاده واحد بسیار بالا است. 👍 این کار تجربه توسعه را ساده می‌کند. پیدا کردن تمام کامپوننت‌های مرتبط برای هر ویژگی آسان است، زیرا آن‌ها به هم نزدیک هستند.
🎯پیاده‌سازی برش‌های عمودی
اگر در حال ساخت یک API هستید، سیستم از قبل به کامندها (POST/PUT/DELETE) و کوئری‌ها (GET) تقسیم می‌شود. با تقسیم کردن درخواست‌ها به کامندها و کوئری‌ها، شما از مزایای الگوی CQRS بهره‌مند می‌شوید. 🚀
برش‌های عمودی به طور محدود روی یک ویژگی واحد تمرکز می‌کنند. این به شما اجازه می‌دهد تا هر مورد استفاده را به صورت جداگانه در نظر گرفته و پیاده‌سازی را متناسب با نیازمندی‌های خاص، سفارشی کنید. یک برش عمودی می‌تواند از EF Core برای پیاده‌سازی یک درخواست GET استفاده کند. برش عمودی دیگری می‌تواند از Dapper با کوئری‌های SQL خام استفاده کند.
یکی دیگر از مزایای پیاده‌سازی برش‌های عمودی به این شکل این است:
✅ ویژگی‌های جدید فقط کد اضافه می‌کنند، شما کد اشتراکی را تغییر نمی‌دهید و نگران عوارض جانبی نیستید.
با این حال، برش‌های عمودی مجموعه چالش‌های خاص خود را دارند. ⚠️ از آنجایی که شما بخش زیادی از منطق بیزینس را داخل یک مورد استفاده واحد پیاده‌سازی می‌کنید، باید قادر به تشخیص code smells باشید. با رشد مورد استفاده، ممکن است در نهایت کار بیش از حدی انجام دهد. شما مجبور خواهید بود با انتقال منطق به دامین، کد را بازآرایی (refactor) کنید.