ساختار سولوشن با الگوی REPR 🧩

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

معماری برش عمودی، از طرف دیگر، کد را حول ویژگی‌ها یا موارد استفاده سازماندهی می‌کند.

یک رویکرد جالب برای ساختاربندی APIها حول ویژگی‌ها، استفاده از الگوی REPR است. این مخفف Request-EndPoint-Response است. این کاملاً با ایده برش‌های عمودی هماهنگ است. شما می‌توانید برای مثال، این را با کتابخانه MediatR به دست آورید.

الگوی REPR تعریف می‌کند که endpointهای وب API باید سه کامپوننت داشته باشند:

1️⃣ Request (درخواست)

2️⃣ Endpoint (نقطه پایانی)

3️⃣ Response (پاسخ)

در اینجا یک مثال از ساختار سولوشن در NET. آمده است. شما پوشه Features را مشاهده خواهید کرد که حاوی برش‌های عمودی است. هر برش عمودی یک درخواست API (یا مورد استفاده) را پیاده‌سازی می‌کند.

📂 RunTracker.API
| 📁 Database
| 📁 Entities
    | #️⃣ Activity.cs
    | #️⃣ Workout.cs
    | #️⃣ ...
| 📁 Features
    | 📁 Activities
        | 📁 GetActivity
            | #️⃣ ActivityResponse.cs
            | #️⃣ GetActivityEndpoint.cs
            | #️⃣ GetActivityQuery.cs
            | #️⃣ GetActivityQueryHandler.cs
        | 📁 CreateActivity
            | #️⃣ CreateActivity.cs
                | #️⃣ CreateActivity.Command.cs
                | #️⃣ CreateActivity.Endpoint.cs
                | #️⃣ CreateActivity.Handler.cs
                | #️⃣ CreateActivity.Validator.cs
    | 📁 Workouts
    | 📁 ...
| 📁 Middleware
| 📄 appsettings.json
| 📄 appsettings.Development.json
| #️⃣ Program.cs

چند کتابخانه دیگر برای پیاده‌سازی الگوی REPR:

🔹 FastEndpoints

🔹 ApiEndpoints

قدم‌های بعدی 🚀

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

ممنون برای مطالعه، و عالی بمانید!🤍