یک فایل در برابر چند فایل: انتخاب شما 📂 vs 🗂

شاید متوجه چیزی شده باشید: من همه چیز را در یک فایل واحد قرار دادم. این یک انتخاب طراحی با مزایا و معایب است.

رویکرد یک فایل (ExportUserData.cs):

public static class ExportUserData
{
    public record Request(Guid UserId) : IRequest<Response>;
    public record Response(string DownloadUrl, DateTime ExpiresAt);
    public class Handler : IRequestHandler<Request, Response> { /* ... */ }
    public class Validator : AbstractValidator<Request> { /* ... */ }
}

رویکرد چند فایل:

📁 ExportData/
├── ExportUserDataCommand.cs
├── ExportUserDataResponse.cs
├── ExportUserDataHandler.cs
├── ExportUserDataValidator.cs
└── ExportUserDataEndpoint.cs

یک فایل عالی است وقتی: ویژگی سرراست است، شما حداکثر نزدیکی و انسجام مکانی (locality) را می‌خواهید، و فایل از چند صد خط کد فراتر نمی‌رود.

تعداد خطوط کد یک قانون سختگیرانه نیست، اما اگر یک فایل فراتر از ۳۰۰-۴۰۰ خط رشد کند، برای خوانایی بهتر، تقسیم آن را در نظر بگیرید. باز هم، این یک موضوع ترجیح تیمی است و یک قانون سخت که من از آن پیروی کنم، نیست. مهم است که به غرایز خود و آنچه برای تیم شما درست به نظر می‌رسد، اعتماد کنید.

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

شما حتی می‌توانید هر دو رویکرد را در یک پروژه ترکیب کنید.

هر دو رویکرد کدهای مرتبط را کنار هم نگه می‌دارند. و این همان چیزی است که در معماری برش عمودی بیشترین اهمیت را دارد.

چرا این واقعاً کار می‌کند (و چگونه شروع کنیم) 🧠

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

نیاز به اصلاح ویژگی خروجی داده دارید؟ همه چیز در پوشه ExportData است. نیازی به جستجو در لایه‌های Controllers, Services, و Repositories نیست. هر برش می‌تواند به طور مستقل تکامل یابد، بنابراین عملیات ساده CRUD ساده باقی می‌مانند در حالی که ویژگی‌های پیچیده مانند خروجی داده می‌توانند از رویکردهای پیشرفته استفاده کنند.

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

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

تمام این مفاهیم به هم گره خورده‌اند تا به شما در ساخت اپلیکیشن‌های NET. قابل نگهداری و مقیاس‌پذیر کمک کنند.