تفاوت Clean Architecture و معماری 3-Layer

اما در این مقاله قصد داریم به بررسی معماری سه لایه بپردازیم. این معماری به طور منطقی کد برنامه شما را به سه قسمت جدا می کند. بیایید ببینیم این لایه ها چیست و چه وظایفی دارند.

معماری Three-layer:

• لایه UI یا Representation layer: این لایه ای است که کاربر مستقیماً با آن تعامل دارد. این لایه یک رابط کاربری است، مکانیزمی برای دریافت ورودی از کاربر. ممکن است شامل controllers و view models و همچنین views باشد که رابط کاربری را تشکیل می‌دهند (صفحات استاتیک HTML، جاوا اسکریپت).
• لایه منطق کسب و کار یا Business logic layer: این لایه شامل مجموعه ای از اجزا است که وظیفه پردازش داده های دریافتی از لایه UI را بر عهده دارند. تمام منطق کاربردی لازم، تمام محاسبات را پیاده سازی می کند. با پایگاه داده تعامل دارد و نتیجه پردازش را به لایه UI منتقل می کند.
• لایه دسترسی به داده یا Data access layer: مدل های داده را ذخیره می کند. همچنین کلاس های خاصی را برای کار با فناوری های مختلف دسترسی به داده ها مانند ORM میزبانی می کند.

نکته مهم در اینجا این است که این لایه ها چگونه به یکدیگر وابسته هستند. Data access layer مستقل از لایه های دیگر است. Business logic layer به Data access layer و Representation layer به Business logic layer بستگی دارد. می توانید آن را با جهت فلش های موجود در نمودار بالا ببینید.

این بدان معناست که داده‌ها و نحوه نگهداری آن‌ها مهم‌ترین بخش برنامه است. این به این دلیل است که بیشتر برنامه به Data access layer است و هرگونه تغییر در فناوری های این لایه مستلزم تغییر در لایه های دیگر است.

جدای از آن، باید توجه داشت که Representation layer نمی‌تواند مستقیماً با Data access layer تعامل داشته باشد. این کار فقط از طریق لایه منطق تجاری قابل انجام است.

معماری تمیز یا Clean Architecture:

معماری تمیز نیز معماری لایه ای است. دامنه لایه (Entities) در مرکز قرار دارد که توسط لایه برنامه (Use Cases) احاطه شده است. لایه بیرونی شامل پورت ها و آداپتورهایی است که برنامه را با سیستم های خارجی (وب، DB، UI) از طریق کنترلرها، مخازن و ارائه کننده ها تطبیق می دهند.

این معماری دامنه محور است. مدل دامنه را در مرکز برنامه قرار می دهد. مدل دامنه هم رفتار و هم داده ها را در بر می گیرد اما تعامل با پایگاه داده را تعریف نمی کند. تداوم و ارائه مدل دامنه فقط جزئیاتی هستند که تا حد امکان دورتر هستند.

در این معماری هر لایه، به لایه ی داخلی تر وابسته بوده و به آن دسترسی دارد. لایه های داخلی هیچ Reference و اشاره ای به لایه های بالاتر ندارند. هرچند می توانند با ارسال Event آن ها را از وقوع رویدادی باخبر کنند. همانطور که در شکل مشاهده می کنید لایه ی Entity، داخلی ترین لایه بوده و به هیچ لایه ی بیرونی وابستگی ندارد.

لایه Entities:

قوانین كسب و كار سیستم های بزرگ را احاطه می كنند. Entityها می توانند یک کلاس یا Object باشند که دارای متد هم هست و هم می توانند فقط شامل ساختار خود موجودیت باشند.

لایه Use Cases:

این لایه شامل business rule های مختص هر application می باشد. این business rule ها در واقع همان use case و قوانین تعاملات کاربر نهایی با سیستم می باشد. این use case ها همانند یک هماهنگ کننده (Orchestrate) جریان داده به entity ها یا از entity ها عمل می کنند. این لایه نباید هیچ تاثیری در وضعیت مربوط به entity ها داشته باشد. کار این لایه صرفا هماهنگ کردن جریان داده به Entity ها یا از Entity ها بر اساس Business Rule و Use Case ها می باشد. موارد خارجی مانند UI یا Database نیز نباید تغییری بر لایه Use Case داشته باشد. این لایه از چنین نگرانی هایی جدا شده است. با این حال ما انتظار داریم تغییرات در عملکرد برنامه روی Use case ها و بنابراین نرم افزار موجود در این لایه تأثیر بگذارد. اگر جزئیات یک Use Case تغییر کند، مطمئناً برخی از کدهای این لایه تحت تأثیر قرار می گیرند.

لایه Interface Adapter:

برنامه موجود در این لایه مجوعه ای از Adapter ها است که وظیفه تبدیل Data قابل استفاده در لایه های use case و entity را به فرمت مناسب external tools ها مانند Database یا Web و برعکس برعهده دارد. Viewها و Controllerها در اینجا قرار دارند.

لایه Framework and Drivers:

بیرونی ترین لایه به طور کلی از framework ها و ابزارهایی مانند بانک اطلاعاتی، Web Framework و غیره تشکیل شده است. جزییات اصلی کار ما اینجا هست و اینجا پیاده سازی خواهد شد. پیاده سازی UI جزئیات است، Database جزئیات است.