پیاده سازی DDD - Clean Architecture

قبلا و در دو پست جداگانه به صورت خلاصه در مورد موضوع زیر صحبت کردیم در این پست جزئیات کامل آن را (در هر قسمت شامل مفاهیم و پیاده سازی)با هم مرور خواهیم کرد
آموزش کاربردی DDD in ASP.NET Core - قسمت اول
آموزش کاربردی DDD in ASP.NET Core - قسمت دوم

گاهی اوقات متوجه می شوید که نقض قوانین باعث صرفه جویی در وقت شما می شود اما در کوتاه مدت.

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

اگر از قوانین، اصول، الگوها و بهترین شیوه ها پیروی کنید، codebase شما ساده تر و راحت تر نگهداری می شود و در نتیجه می تواند سریعتر تغییر کند.

طراحی دامنه محور(Domain Driven Design) چیست؟

طراحی دامنه محور (DDD) یک رویکرد برای توسعه نرم افزار با نیازمندیهای پیچیده است. DDD برای دامنه های پیچیده و در مقیاس بزرگ مناسب است و در نهایت به ایجاد یک کد انعطاف پذیر، ماژولار و قابل نگهداری کمک می کند.

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

پیاده سازی DDD به شدت به شی گرایی OOP و اصول SOLID متکی است بنابراین درک OOP & SOLID واقعا کمک زیادی به شما در پیاده سازی DDD خواهد کرد.

لایه ها در DDD و Clean Architecture

همانطور که درتصویر بالا ملاحظه می کنید در معماری پروژه های DDD چهار لایه اساسی وجود دارد.

این معماری لایه Business Logic را در دو لایه قرار می دهد، لایه Domain ولایه Application ، در حالی که آنها شامل انواع مختلفی از business logic هستند.

لایه Domain

بیشتر بخوانید : لایه Domain در طراحی دامنه گرا DDD

اینجا مرکز سیستم و قلب برنامه است. دامنه بیشتر منطق کسب و کار سیستم را کنترل می کند. این لایه همچنین وظیفه تعریف مفاهیم، ​​رفتارها و قوانین را بر عهده دارد. لایه های باقی مانده آنها را پیاده سازی می کنند.اما قبل از هر چیز و برای پیاده سازی Domain Model نیاز به دانستن مفاهیم و اجزای سازنده آن داریم :

• Entities (مفاهیم / پیاده سازی)
• Value Objects (مفاهیم / پیاده سازی)
• Aggregate & Aggregate Root (مفاهیم / پیاده سازی)
• Repositories (مفاهیم / پیاده سازی)
• Domain Services(مفاهيم /پياده سازي)
• Specifications(مفاهيم/پياده سازي)
• Domain Event(مفاهیم / پیاده سازی)
• Factories(مفاهیم)

لایه Application

لایه Domain باید کاملاً از بقیه سیستم جدا باشد. با این حال، چیزی باید مقادیر خاص UI (query strings POST data, session و غیره) را به اشیاء Domain ترجمه کند. این لایه به عنوان دروازه ای عمل می کند که در آن برنامه ها (Presentation Layer) با سیستم تعامل دارند. این لایه اطلاعات جمع آوری شده از تعاملات بین برنامه و کاربران نهایی یا خدمات شخص ثالث(third-party services) را پردازش می کند. درخواست‌ها را دریافت می‌کند و قبل از ارسال آن‌ها به دامنه(Domain) برای پردازش، ورودی را تأیید(validates) می‌کند. لایه Application همچنین پاسخ هایی(responses) را به Presentation Layer ارائه می دهد. و به طور موثر دامنه را از بقیه سیستم پنهان کند.

مسئولیت های لایه Application

• مسئول ناوبری بین صفحات رابط کاربری(UI screens) در bounded context و همچنین تعامل با لایه های برنامه سایر bounded contextها است.
• می تواند اعتبارسنجی اولیه (غیر مرتبط با business) را روی داده های ورودی کاربر قبل از انتقال آن به لایه های دیگر (پایین) برنامه انجام دهد.
• حاوی هیچ منطق مرتبط با business یا دامنه نیست.
• هیچ حالتی ندارد که منعکس کننده یک busines use case باشد، اما می تواند وضعیت session کاربر یا پیشرفت یک کار را مدیریت کند.
• شامل Application Services است.

و اما مهمترین مفاهیمی در لایه Application :

• Application Services(مفاهیم / پیاده سازی)
• Data Transfer Objects/DTO(مفاهیم/پیاده سازی)

لایه Presentation

شامل عناصر UI از جمله pages و components و ...

لایه Infrastructure

لایه زیرساخت از لایه های دیگر پشتیبانی می کند پیاده سازی انتزاعات (abstractions)و...

این لایه شامل مواردی مانند تماس های API به API های شخص ثالث است.

این لایه لایه ای خواهد بود که به سرویس های خارجی مانند پایگاه داده، سیستم های پیام رسانی و سرویس های ایمیل دسترسی دارد.

همان لایه بندی را می توان مانند نمودار زیر نشان داد معروف به Clean Architecture یا گاهی Onion Architecture :

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

بیشترین تمرکز طراحی دامنه محور لایه های Domain و Application می باشد و لایه های Presentation و Infrastructure را به نوعی نادیده می گیرد اما این به معنای کم اهمیت بودن آن نیست، آنها بسیار مهم هستند.

در پست های بعدی یک پیاده سازی کامل در قالب یک پروژه فرضی را با هم شروع خواهیم کرد.

بیشتر بخوانید : نقشه راه توسعه دهندگان Asp.NET Core

https://zarinp.al/farshidazizi