خبرهای وبلاگ

نگاهی به معماری تمیز Clean Architecture

معماری تمیز
معماری تمیز

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

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

به طور کلی در معماری Clean می توانیم  پروژه را به 5 لایه تقسیم بندی کنیم.

  1. Domain
  2. Application
  3. Presentation
  4. Infrastructure
  5. Persistence

در ادامه کارکرد های هر یک از این لایه ها را معرفی می کنیم.

لایه ی Domain

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

لایه ی Application

سرویس ها در این لایه تعریف میشوند. این لایه به عنوان هسته ی اصلی پروژه در نظر گرفته میشود و در آن عملیات هایی مانند اعتبار سنجی وذخیره و بازیابی اطلاعات از دیتابیس انجام میشود. همچنین قوانین تجاری حاکم بر برنامه در این لایه تعریف میشود. مثلا اگر می خواهید به مشتریان وفادار فروشگاه بر اساس میزان خرید جایزه دهید در این لایه کدهایش را پیاده می کنید. معمولا برای هر بخش پروژه یک فولدر جدا درست میکنیم مثلا یک فولدر برای سفارشها و یک فولدر برای محصولات ایجاد می کنیم و تمامی کلاسهای مربوط به هر بخش را در یک محل نگه داری می کنیم.

لایه ی Presentation

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

لایه ی Infrastructure

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

لایه ی Persistence

این لایه در اصل بخشی از لایه ی Infrastructure است.  اما از آنجا که در ASP.NET Core ما همیشه از EF Core برای ارتباط با دیتابیس استفاده میکنیم بهتر است این بخش را به صورت مجزا نگه داری کنیم. در این لایه تعریف دیتابیس و ارتباط بین جدول ها از طریق  EF Core معمولا به روش Code First انجام میشود. بر مبنای همان اصلی که در Infrastrucuture تعریف شد باید بتوان دیتابیس را بدون تغییر سایر کدها عوض کرد و EF Core در این مسئله به کمک ما می آید. البته در خیلی از پروژه ها ما هیچوقت دیتابیس را تغییر نمیدهیم و می توانیم با وسواس کمتری این لایه را پیاده کنیم.

چند نکته

  • رفرنس دهی باید از بالا به پایین باشد. یعنی لایه ی دوم (Application)می تواند به لایه ی اول (Domain) وابسته باشد اما نباید عکس آن روی دهد.
  • در این معماری بجای استفاده از لایه ی Repository و Unit Of Work از EF Core استفاده می کنیم. در بسیاری از موارد نیازی به پیاده سازی لایه های ریپوزیتوری نداریم و می توانیم از آن صرف نظر کنیم.
  • همچنین در این تقسیم بندی از Fluent API در EF Core استفاده می کنیم. در واقع وقتی کلاسهای Entity را درون لایه ی دامین تعریف می کنیم از اتریبیوت ها برای تنظیم خصوصیات جدول و رابطه ی آن با جداول دیگر استفاده نمیکنیم.
  • می توانیم برای هر لایه پروژه های جدا داشته باشیم یا همه ی آنها را به صورت فولدر در یک پروژه قرار دهیم. ایجاد پروژه های جدا اصولی تر است اما سولوشن را شلوغ میکند و مجبور نیستید پروژه را با این حالت شروع کنید. در آینده همیشه می توانید هر فولدر را به پروژه ی خودش منتقل کنید.
  • در پروژه های بزرگتر پیشنهاد میشود در لایه ی Application بجای Service از روش CQRS استفاده شود. در این روش عملیاتهای ثبت و گزارش گیری از دیتابیس به صورت کلاسهای مجزا تعریف میشوند.
  • در لایه ی Presentation استفاده از Razor Page بجای Controller توصیه میشود. در این روش برای هر صفحه یک کلاس مجزا ایجاد میشود و اصل Single Responsibility بهتر پیاده میشود.

نتیجه گیری

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

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

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