برنامه نویسی

1 – معماری پاک: رویکردی ساده تر برای طراحی نرم افزار

Summarize this content to 400 words in Persian Lang
سلام به همه، به اولین پست از مجموعه ای خوش آمدید که در آن به بررسی آن خواهیم پرداخت معماری پاک و اینکه چگونه می تواند به ما در نوشتن کدهای قابل نگهداری، مقیاس پذیر و قابل آزمایش بیشتر کمک کند. اگر تا به حال با وابستگی های درهم، کد سفت و سخت یا مشکل در آزمایش دست و پنجه نرم کرده اید، Clean Architecture می تواند یک تغییر دهنده بازی برای شما باشد. در این مجموعه، مفاهیم را گام به گام با استفاده از مثال‌هایی در سی شارپ – به‌ویژه در مورد سیستم پردازش حقوق و دستمزد، تجزیه می‌کنم.

بیایید از اصول اولیه شروع کنیم: معماری پاک چیست؟

معماری پاک چیست؟

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

اصطلاح معماری پاک توسط عمو باب (رابرت سی. مارتین) و ایده اصلی آن سازماندهی کد در لایه ها با مهمترین لایه (شما منطق کسب و کار) در مرکز، و اجزای کمتر مهم (UI، پایگاه داده) در لبه های بیرونی.

هر چه بیشتر از هسته دور شوید، کد باید پایدارتر و کمتر اهمیت داشته باشد. لایه‌های مرکزی باید پایدارترین باشند و چیزهایی مانند پایگاه‌های داده و چارچوب‌های UI که احتمالاً تغییر می‌کنند، در خارج نگه داشته می‌شوند.

لایه های معماری پاک

معماری پاک اغلب به صورت مجموعه ای از دایره های متحدالمرکز به تصویر کشیده می شود که هر دایره نشان دهنده یک لایه است. در اینجا خلاصه ای سریع از این لایه ها آمده است:

نهادها: اینها قوانین اصلی تجارت هستند. آنها مهمترین بخش سیستم هستند و نباید به چیزی خارج از منطق تجاری وابسته باشند.
موارد استفاده: این لایه قوانین تجاری خاص برنامه را تعریف می کند. همه چیز مربوط به کاری است که برنامه انجام می دهد. این لایه با موجودیت ها تعامل دارد و جریان های برنامه را تعریف می کند.
آداپتورهای رابط: این لایه حاوی کدی است که داده های دنیای بیرون را به قالبی تبدیل می کند که موارد استفاده و موجودیت ها بتوانند آن را درک کنند و بالعکس. این می تواند شامل کنترل کننده ها، ارائه کننده ها یا دروازه هایی برای برقراری ارتباط با سیستم های خارجی باشد.
چارچوب ها و درایورها: این خارجی ترین لایه است که شامل چارچوب وب، پایگاه داده و سایر جزئیات است. اینها ابزارهایی هستند که اغلب در معرض تغییر هستند و باید کمترین تأثیر را روی لایه های داخلی داشته باشند.

چرا از معماری پاک استفاده کنیم؟

اکنون، ممکن است از خود بپرسید، “چرا این همه تلاش را انجام دهید؟” سوال خوب! در اینجا برخی از مزایای استفاده از Clean Architecture آورده شده است:

آزمایش پذیری: از آنجایی که منطق اصلی مستقل از رابط کاربری و پایگاه داده است، نوشتن تست برای آن بسیار آسان تر است.

قابلیت نگهداری: تغییرات در یک بخش از سیستم، مانند UI یا پایگاه داده، به منطق اصلی تجارت وارد نمی شود. این جداسازی به کاهش باگ ها کمک می کند و سیستم را آسان تر می کند.

انعطاف پذیری: آیا نیاز به تغییر از پایگاه داده SQL به NoSQL دارید؟ یا شاید از یک چارچوب رابط کاربری قدیمی به یک چارچوب جدید مهاجرت کنید؟ معماری پاک این تغییرات را آسان تر می کند زیرا هسته سیستم شما از این جزئیات جدا شده است.

منطق کسب و کار کجا می رود؟

یک تصور غلط رایج این است که ما باید منطق کسب و کار را مستقیماً وارد خود کنیم نهادها. با این حال، در معماری پاک، از این کار جلوگیری می شود. را نهادها فقط باید قوانین اساسی کسب و کار را نشان دهد، در حالی که منطق کاربردی پیچیده- مانند اجرای یک گردش کار مانند پردازش حقوق و دستمزد – باید در این قسمت وجود داشته باشد موارد استفاده.

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

شروع کوچک: یک مثال ساده حقوق و دستمزد

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

در اینجا نحوه لایه اول، نهادها، ممکن است در سی شارپ نگاه کنید:

public class Employee
{
public int Id { get; set; }
public string Name { get; set; }
public decimal Salary { get; set; }
public decimal TaxRate { get; set; }

public Employee(int id, string name, decimal salary, decimal taxRate)
{
Id = id;
Name = name;
Salary = salary;
TaxRate = taxRate;
}

public void ValidateTaxRate()
{
if (TaxRate < 0 || TaxRate > 1)
{
throw new ArgumentException(“Invalid tax rate”);
}
}
}

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

اینجا چه خبر است؟

ما یک ساده ایجاد کرده ایم Employee کلاسی که یک موجودیت را در سیستم حقوق و دستمزد ما نشان می دهد. را Employee کلاس ویژگی های اساسی مانند را تعریف می کند Id، Name، Salary، و TaxRate. همچنین شامل یک روش می باشد ValidateTaxRate() برای اطمینان از اینکه نرخ مالیات در محدوده های معتبر است.

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

مدیریت منطق کسب و کار در یک مورد استفاده

حال، بیایید منطق تجاری را که محاسبه می کند، در نظر بگیریم حقوق خالص و آن را در یک مورد استفاده قرار دهید. در اینجا چیزی است که ممکن است به نظر برسد:

public class ProcessPayrollUseCase
{
public decimal CalculateNetSalary(Employee employee)
{
employee.ValidateTaxRate();
return employee.Salary – (employee.Salary * employee.TaxRate);
}
}

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

در این ProcessPayrollUseCase، محاسبه حقوق خالص کارمند پس از کسر مالیات را انجام می دهیم. use case مسئول اجرای آن است منطق کسب و کار که از ما استفاده می کند Employee نهاد، و قبل از انجام محاسبه، نرخ مالیات را تأیید می کند.

این جدایی تضمین می کند موجودیت ها ساده می مانند، و منطق کسب و کار در موارد استفاده سازماندهی می شود که به آن تعلق دارد.

بعد چه می شود؟

در این پست، ما اصول اولیه معماری پاک را پوشش داده ایم و صحنه را با اولین موجود خود آماده کرده ایم. در پست بعدی بیشتر به این موضوع خواهیم پرداخت موارد استفاده- قوانین تجاری خاص برنامه که نحوه رفتار سیستم را کنترل می کند. به طور خاص، نحوه پردازش حقوق و دستمزد با استفاده از اصول معماری پاک و ساخت بر اساس این کلاس Employee را بررسی خواهیم کرد.

با ما همراه باشید!

سلام به همه، به اولین پست از مجموعه ای خوش آمدید که در آن به بررسی آن خواهیم پرداخت معماری پاک و اینکه چگونه می تواند به ما در نوشتن کدهای قابل نگهداری، مقیاس پذیر و قابل آزمایش بیشتر کمک کند. اگر تا به حال با وابستگی های درهم، کد سفت و سخت یا مشکل در آزمایش دست و پنجه نرم کرده اید، Clean Architecture می تواند یک تغییر دهنده بازی برای شما باشد. در این مجموعه، مفاهیم را گام به گام با استفاده از مثال‌هایی در سی شارپ – به‌ویژه در مورد سیستم پردازش حقوق و دستمزد، تجزیه می‌کنم.

بیایید از اصول اولیه شروع کنیم: معماری پاک چیست؟

معماری پاک چیست؟

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

اصطلاح معماری پاک توسط عمو باب (رابرت سی. مارتین) و ایده اصلی آن سازماندهی کد در لایه ها با مهمترین لایه (شما منطق کسب و کار) در مرکز، و اجزای کمتر مهم (UI، پایگاه داده) در لبه های بیرونی.

هر چه بیشتر از هسته دور شوید، کد باید پایدارتر و کمتر اهمیت داشته باشد. لایه‌های مرکزی باید پایدارترین باشند و چیزهایی مانند پایگاه‌های داده و چارچوب‌های UI که احتمالاً تغییر می‌کنند، در خارج نگه داشته می‌شوند.

لایه های معماری پاک

معماری پاک اغلب به صورت مجموعه ای از دایره های متحدالمرکز به تصویر کشیده می شود که هر دایره نشان دهنده یک لایه است. در اینجا خلاصه ای سریع از این لایه ها آمده است:

  1. نهادها: اینها قوانین اصلی تجارت هستند. آنها مهمترین بخش سیستم هستند و نباید به چیزی خارج از منطق تجاری وابسته باشند.

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

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

  4. چارچوب ها و درایورها: این خارجی ترین لایه است که شامل چارچوب وب، پایگاه داده و سایر جزئیات است. اینها ابزارهایی هستند که اغلب در معرض تغییر هستند و باید کمترین تأثیر را روی لایه های داخلی داشته باشند.

چرا از معماری پاک استفاده کنیم؟

اکنون، ممکن است از خود بپرسید، “چرا این همه تلاش را انجام دهید؟” سوال خوب! در اینجا برخی از مزایای استفاده از Clean Architecture آورده شده است:

  • آزمایش پذیری: از آنجایی که منطق اصلی مستقل از رابط کاربری و پایگاه داده است، نوشتن تست برای آن بسیار آسان تر است.
  • قابلیت نگهداری: تغییرات در یک بخش از سیستم، مانند UI یا پایگاه داده، به منطق اصلی تجارت وارد نمی شود. این جداسازی به کاهش باگ ها کمک می کند و سیستم را آسان تر می کند.
  • انعطاف پذیری: آیا نیاز به تغییر از پایگاه داده SQL به NoSQL دارید؟ یا شاید از یک چارچوب رابط کاربری قدیمی به یک چارچوب جدید مهاجرت کنید؟ معماری پاک این تغییرات را آسان تر می کند زیرا هسته سیستم شما از این جزئیات جدا شده است.

منطق کسب و کار کجا می رود؟

یک تصور غلط رایج این است که ما باید منطق کسب و کار را مستقیماً وارد خود کنیم نهادها. با این حال، در معماری پاک، از این کار جلوگیری می شود. را نهادها فقط باید قوانین اساسی کسب و کار را نشان دهد، در حالی که منطق کاربردی پیچیده– مانند اجرای یک گردش کار مانند پردازش حقوق و دستمزد – باید در این قسمت وجود داشته باشد موارد استفاده.

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

شروع کوچک: یک مثال ساده حقوق و دستمزد

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

در اینجا نحوه لایه اول، نهادها، ممکن است در سی شارپ نگاه کنید:



public class Employee
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Salary { get; set; }
    public decimal TaxRate { get; set; }

    public Employee(int id, string name, decimal salary, decimal taxRate)
    {
        Id = id;
        Name = name;
        Salary = salary;
        TaxRate = taxRate;
    }

    public void ValidateTaxRate()
    {
        if (TaxRate < 0 || TaxRate > 1)
        {
            throw new ArgumentException("Invalid tax rate");
        }
    }
}


وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

اینجا چه خبر است؟

ما یک ساده ایجاد کرده ایم Employee کلاسی که یک موجودیت را در سیستم حقوق و دستمزد ما نشان می دهد. را Employee کلاس ویژگی های اساسی مانند را تعریف می کند Id، Name، Salary، و TaxRate. همچنین شامل یک روش می باشد ValidateTaxRate() برای اطمینان از اینکه نرخ مالیات در محدوده های معتبر است.

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

مدیریت منطق کسب و کار در یک مورد استفاده

حال، بیایید منطق تجاری را که محاسبه می کند، در نظر بگیریم حقوق خالص و آن را در یک مورد استفاده قرار دهید. در اینجا چیزی است که ممکن است به نظر برسد:



public class ProcessPayrollUseCase
{
    public decimal CalculateNetSalary(Employee employee)
    {
        employee.ValidateTaxRate();
        return employee.Salary - (employee.Salary * employee.TaxRate);
    }
}


وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

در این ProcessPayrollUseCase، محاسبه حقوق خالص کارمند پس از کسر مالیات را انجام می دهیم. use case مسئول اجرای آن است منطق کسب و کار که از ما استفاده می کند Employee نهاد، و قبل از انجام محاسبه، نرخ مالیات را تأیید می کند.

این جدایی تضمین می کند موجودیت ها ساده می مانند، و منطق کسب و کار در موارد استفاده سازماندهی می شود که به آن تعلق دارد.

بعد چه می شود؟

در این پست، ما اصول اولیه معماری پاک را پوشش داده ایم و صحنه را با اولین موجود خود آماده کرده ایم. در پست بعدی بیشتر به این موضوع خواهیم پرداخت موارد استفاده– قوانین تجاری خاص برنامه که نحوه رفتار سیستم را کنترل می کند. به طور خاص، نحوه پردازش حقوق و دستمزد با استفاده از اصول معماری پاک و ساخت بر اساس این کلاس Employee را بررسی خواهیم کرد.

با ما همراه باشید!

نوشته های مشابه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دکمه بازگشت به بالا