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

برای مثال، در معماری تمیز (Clean Architecture): ⛓️

🔹 Domain
نباید هیچ وابستگی داشته باشد.

🔹 لایه Application می‌تواند به Domain ارجاع دهد.

🔹 Infrastructure
می‌تواند هم به Application و هم به Domain ارجاع دهد.

🔹 Presentation
می‌تواند هم به Application و هم به Domain ارجاع دهد.

شما در نهایت به coupling بالا در داخل یک لایه و coupling پایین بین لایه‌ها می‌رسید. این به این معنی نیست که معماری‌های لایه‌ای بد هستند. اما به این معنی است که شما انتزاع‌های (abstractions) زیادی بین لایه‌های مجزا خواهید داشت. و انتزاع‌های بیشتر به معنای افزایش پیچیدگی است 🤯 زیرا کامپوننت‌های بیشتری برای نگهداری وجود دارد.

معماری برش عمودی (Vertical Slice Architecture) چیست؟ 🤔

من برای اولین بار در مورد معماری برش عمودی از جیمی بوگارد شنیدم. او همچنین خالق برخی کتابخانه‌های متن‌باز محبوب مانند MediatR و Automapper است.

معماری برش عمودی از درد کار با معماری‌های لایه‌ای متولد شد. آن‌ها شما را مجبور می‌کنند برای پیاده‌سازی یک ویژگی، تغییراتی در لایه‌های بسیار متفاوتی ایجاد کنید.

بیایید تصور کنیم افزودن یک ویژگی جدید در یک معماری لایه‌ای چگونه به نظر می‌رسد: 📝

🔹 به‌روزرسانی مدل دامین

🔹 اصلاح منطق اعتبارسنجی

🔹 ایجاد یک مورد استفاده با MediatR

🔹 ارائه یک endpoint API از یک کنترلر

انسجام پایین است زیرا شما در حال ایجاد فایل‌های زیادی در لایه‌های مختلف هستید.

برش‌های عمودی رویکرد متفاوتی را در پیش می‌گیرند:

کوپلینگ بین برش‌ها را به حداقل برسانید و کوپلینگ را در یک برش به حداکثر برسانید. 🎯