معماری ها همان هدف را دارند – تفکیک روابط. همه آنها با تقسیم نرم افزار به لایه‌ها به آن می رسند.

– Uncle Bob

لایه ها

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

چرا برنامه را به لایه ها تقسیم می کنیم

• اصل Single Responsibility را حفظ می کند.
• جدایی از نگرانی ها را دنبال می کند.
• نقش ها و مهارت های توسعه را جدا می کند. (لایه ارائه – توسعه دهنده فرانت اند، لایه تجاری – توسعه دهنده بک‌اند)
• از پیاده سازی های متعدد پشتیبانی می کند. (لایه ارائه قابل تعویض)
• متغیر بودن نرخ تغییر.
• برش برنامه را به واحدهای قابل کنترل تر

الگوی معماری لایه ای

این رایج ترین الگوی معماری است که به آن الگوی معماری n-tier نیز می گویند. برای اکثر معماران و توسعه دهندگان OOP استاندارد می شود.

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

معماری سه لایه

معماری سه لایه کاربرد اصلی CRUD است. منظور من از CRUD ، نرم افزاری است که بیشتر مورد استفاده برای ایجاد (Create) ، خواندن (Read) ، به روزرسانی (Update) یا حذف (Delete) چیزی است.
من معماری دامنه محور پیچیده تری را برای چنین سیستم هایی توصیه نمی کنم. اگر معماری دامنه محور را برای سیستم های CRUD انتخاب کنید ، متوجه می شوید که با گذشت زمان هیچ ماده ای برای مدل سازی دامنه وجود ندارد.

Presentation Layer

همانطور که از نام آن مشخص است ، لایه ارائه دارای کد و فن آوری هایی برای تجربه کاربر است. بنابراین ، من در مورد چارچوب های توسعه وب مانند Angular یا Blazor ، چارچوب های دسکتاپ کمتر استفاده شده مانند WPF یا WinForms و چارچوب های توسعه تلفن همراه به عنوان مثال Xamarin صحبت می کنم.
الگوهای ارائه مانند MVVM یا MVC نیز بخشی از این لایه هستند. قسمت BackEnd این الگوها فقط باید با مدلهای ارائه (ساختارهای داده ارائه) کار کنند.
هنگامی که نیاز به پیاده سازی رفتار ، دستور ، پرس و جو یا برخی از ارتباطات موجود با سیستم های خارجی وجود دارد ، نشانه این است که این کد به جای دیگری تعلق دارد. دقیق تر بگویم، به لایه تجاری (Business Layer).

Business Layer

Business Layer کدی پر از مسئولیت معنای وجودی نرم افزار است. برنامه شما وجود ندارد زیرا یک برنامه تلفن همراه است یا از Azure SQL Server استفاده می کند. وجود دارد زیرا هدف خود را دارد و الگوریتم های پیاده سازی این هدف متعلق به Business Layer است.
ورودی لایه ساختارهای داده ای است که از Presentation Layer دریافت می شود و سایر ساختارهای انتهایی داده ها از لایه Data Access است. خروجی ساختارهای داده ای است که توسط Presentation Layer یا ساختارهای داده مورد انتظار لایه Access Data است.

فرم ساختار داده های خروجی Business Layer باید تا حد ممکن دو لایه دیگر را برآورده کند. موارد استفاده و رفتارها اصلاح کننده های مسئول چنین شکل دهی هستند.
روش های بیشتری برای مقابله با طراحی Business Layer وجود دارد. Command Query Responsibility Separation یا CQRS یکی از آنهاست.

Data Access Layer

لایه دسترسی به داده مسئول اتصال به پایداری است. متداولترین تداوم یک پایگاه داده رابطه ای است ، بنابراین لایه دسترسی به داده اغلب حاوی چارچوب نقشه برداری رابطه ای شی (ORM) مانند Entity Framework Core یا Hibernate است.
اگر مانند من از Entity Framework Core استفاده می کنید ، این لایه ای است که در آن شما نهادها و پایگاه داده را طراحی خواهید کرد.

منبع : medium