آموزش معماری تمیز Clean Architecture در ASP.NET Core 3

آموزش معماری تمیز Clean Architecture در ASP.NET Core 3 یکی دیگر از آموزش های گروه آموزشی پرووید می باشد که در این قسمت آن را به شما معرفی می کنیم. این آموزش نیز یکی از دوره های آموزشی دیگر که در حوزه ی فارسی سازی آموزش های انگلیسی تنظیم شده است می باشد. این آموزش به زبان انگلیسی از وبسایت یوتیوب منتشر شده است و در این قسمت به صورت فارسی به شما تقدیم می گردد.

معماری تمیز (Clean Architecture) چیست؟

طی سال‌های اخیر ظهر تعداد زیادی از ایده های متنوع برای معماری موفق یک سیستم نرم‌افزاری را شاهد بوده ایم. بعضی از این موارد شامل معماری های زیر می باشند که توسط افراد مختلف تنظیم شده اند:

• معماری Hexagonal Architecture که تحت عنوان Ports and Adapters نیز شناخته می شود.
• معماری Growing Object Oriented Software
• معماری Onion Architecture
• معماری Screaming Architecture
• معماری DCI
• معماری BCE که در کتاب Object Oriented Software Engineering: A Use-Case Driven Approach مطرح شده است.

هرچند که این معماری ها کمی در جزئیات با یکدیگر متفاوت هستند اما اساس کار آن ها و اهدافی که دنبال می‌کنند یکسان می باشد. هدف تمامی این معماری ها تفکیک کردن قسمتهای مختلف برنامه و یا separation of concerns می باشد. این هدف مهم با شکستن یک نرم‌افزار به لایه های مختلف انجام می پذیرد. تمامی این معماری ها حداقل یک لایه برای قوانین تجاری و یا business rule ها در نظر می گیرند و یک لایه دیگر برای اینترفیس ها. در این رابطه می توانید از آموزش اینترفیس ها در سی شارپ نیز استفاده کنید.

ویژگی های معماری تمیز (Clean Architecture)

معماری هایی که از آنها صحبت کردیم سیستم‌های را ایجاد می‌کنند که دارای ویژگی های زیر می باشند:

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

قابلیت تست پذیر بودن: قوانین تجاری می‌توانند بدون درگیر کردن دیتابیس و یا واسط کاربری برنامه و یا هر عنصر خارجی دیگری به راحتی تست بشوند. موضوع تست پذیری یک موضوع بسیار مهم در توسعه نرم‌افزار است. در این رابطه می توانید از آموزش نکات طلایی تست واحد Unit Test پیشرفته در سی شارپ استفاده کنید.

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

مستقل از دیتابیس: به سادگی می توانید از سیستم های دیتابیس مختلف از قبیل Oracle و SQL Server و for Mongo و BigTable و CouchDB استفاده کنید. قوانین تجاری شما هیچ وابستگی به دیتابیس نخواهند داشت.

مستقل از هر عنصر خارجی: با اعمال این معماری ها قوانین تجاری و یا همان business rule های شما به هیچ وجه جزئیاتی در رابطه با دنیای خارجی نمی دانند و به آن وابستگی نخواهند داشت.

Clean Architecture چگونه ساختار پروژه ASP.NET Core را بهبود می دهد؟

Clean Architecture یا معماری تمیز رویکردی برای سازمان دهی نرم افزار است که هدف آن جدا نگه داشتن منطق اصلی برنامه از جزئیات اجرایی و فناوری‌های بیرونی است. در این معماری، قواعد کسب‌وکار نباید به شکل مستقیم به پایگاه داده، رابط کاربری یا چارچوب وب وابسته باشند. این جداسازی باعث می‌شود تغییر یک فناوری جانبی لزوماً نیازمند بازنویسی منطق اصلی برنامه نباشد. در پروژه‌های ASP.NET Core، این رویکرد می‌تواند به ایجاد ساختاری منظم‌تر و قابل نگهداری‌تر کمک کند.

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

لایه های اصلی در معماری تمیز چه مسئولیت هایی دارند؟

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

در ASP.NET Core، بخش مربوط به دریافت درخواست‌های HTTP معمولاً در لایه بیرونی قرار می‌گیرد و می‌تواند عملیات مورد نیاز را به لایه‌های داخلی واگذار کند. دسترسی به پایگاه داده یا سرویس‌های خارجی نیز می‌تواند پشت قراردادهایی قرار بگیرد که بخش‌های مرکزی برنامه از آن‌ها استفاده می‌کنند. این ساختار کمک می‌کند اجزای مختلف مسئولیت‌های مشخصی داشته باشند و تغییر فناوری‌های بیرونی با منطق اصلی کمتر تداخل پیدا کند. طراحی درست لایه‌ها باید با اندازه و پیچیدگی واقعی پروژه متناسب باشد.

ارتباط Clean Architecture با Dependency Injection و تست پذیری

Dependency Injection روشی برای تأمین وابستگی‌های یک کلاس از بیرون آن است و می‌تواند در پیاده سازی Clean Architecture نقش مهمی داشته باشد. با تعریف قراردادهای مشخص و ارائه پیاده سازی مناسب هنگام راه‌اندازی برنامه، بخش‌های اصلی می‌توانند بدون ساخت مستقیم وابستگی‌های زیرساختی فعالیت کنند. برای مثال، منطق یک عملیات می‌تواند به یک قرارداد برای ذخیره اطلاعات وابسته باشد، در حالی که پیاده سازی واقعی این قرارداد در لایه زیرساخت قرار می‌گیرد. این جداسازی تغییر و جایگزینی وابستگی‌ها را آسان‌تر می‌کند.

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

چه زمانی استفاده از Clean Architecture در ASP.NET Core مناسب است؟

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

با این حال، استفاده از لایه‌های متعدد برای هر برنامه‌ای ضروری نیست. یک پروژه کوچک با منطق ساده ممکن است با ساختاری سبک‌تر نیز به‌خوبی قابل نگهداری باشد. انتخاب معماری باید بر اساس نیازهای واقعی، پیچیدگی دامنه و هزینه نگهداری انجام شود، نه صرفاً پیروی از یک الگوی رایج. این آموزش برای توسعه دهندگانی مناسب است که با ASP.NET Core آشنایی دارند و می‌خواهند روش طراحی ساختارمندتری را برای مدیریت وابستگی‌ها، تفکیک مسئولیت‌ها و آماده‌سازی برنامه برای توسعه آینده بررسی کنند.