قبلا و در دو پست جداگانه به صورت خلاصه در مورد موضوع زیر صحبت کردیم در این پست جزئیات کامل آن را (در هر قسمت شامل مفاهیم و پیاده سازی)با هم مرور خواهیم کرد
آموزش کاربردی DDD in ASP.NET Core - قسمت اول
آموزش کاربردی DDD in ASP.NET Core - قسمت دوم
گاهی اوقات متوجه می شوید که نقض قوانین باعث صرفه جویی در وقت شما می شود اما در کوتاه مدت.
با این حال، در کوتاه مدت شما زمان ذخیره شده به ارمغان خواهید آورد. اما در میان مدت و بلند مدت زمان بسیار بیشتری را از دست خواهید داد!!!
codebase شما پیچیده و نگهداری آن سختر می شود. برنامه های تجاری فقط به این دلیل که شما دیگر نمی توانید آن را به سادگی نگهداری کنید و یا توسعه دهید دوباره نوشته می شوند.
اگر از قوانین، اصول، الگوها و بهترین شیوه ها پیروی کنید، codebase شما ساده تر و راحت تر نگهداری می شود و در نتیجه می تواند سریعتر تغییر کند.
طراحی دامنه محور (DDD) یک رویکرد برای توسعه نرم افزار با نیازمندیهای پیچیده است. DDD برای دامنه های پیچیده و در مقیاس بزرگ مناسب است و در نهایت به ایجاد یک کد انعطاف پذیر، ماژولار و قابل نگهداری کمک می کند.
قبلا در این لینک مختصرا در خصوص اینکه طراحی دامنه محور چیست، چرا به آن نیاز داریم؟ همچنین مزایا و معایب آن صحبت کردیم. پیشنهاد می کنم قبل از مطالعه ادامه این پست حتما آن نگاهی به آن بیاندازید.
پیاده سازی DDD به شدت به شی گرایی OOP و اصول SOLID متکی است بنابراین درک OOP & SOLID واقعا کمک زیادی به شما در پیاده سازی DDD خواهد کرد.
همانطور که درتصویر بالا ملاحظه می کنید در معماری پروژه های DDD چهار لایه اساسی وجود دارد.
این معماری لایه Business Logic را در دو لایه قرار می دهد، لایه Domain ولایه Application ، در حالی که آنها شامل انواع مختلفی از business logic هستند.
بیشتر بخوانید : لایه Domain در طراحی دامنه گرا DDD
اینجا مرکز سیستم و قلب برنامه است. دامنه بیشتر منطق کسب و کار سیستم را کنترل می کند. این لایه همچنین وظیفه تعریف مفاهیم، رفتارها و قوانین را بر عهده دارد. لایه های باقی مانده آنها را پیاده سازی می کنند.اما قبل از هر چیز و برای پیاده سازی Domain Model نیاز به دانستن مفاهیم و اجزای سازنده آن داریم :
لایه Domain باید کاملاً از بقیه سیستم جدا باشد. با این حال، چیزی باید مقادیر خاص UI (query strings POST data, session و غیره) را به اشیاء Domain ترجمه کند. این لایه به عنوان دروازه ای عمل می کند که در آن برنامه ها (Presentation Layer) با سیستم تعامل دارند. این لایه اطلاعات جمع آوری شده از تعاملات بین برنامه و کاربران نهایی یا خدمات شخص ثالث(third-party services) را پردازش می کند. درخواستها را دریافت میکند و قبل از ارسال آنها به دامنه(Domain) برای پردازش، ورودی را تأیید(validates) میکند. لایه Application همچنین پاسخ هایی(responses) را به Presentation Layer ارائه می دهد. و به طور موثر دامنه را از بقیه سیستم پنهان کند.
مسئولیت های لایه Application
و اما مهمترین مفاهیمی در لایه Application :
شامل عناصر UI از جمله pages و components و ...
لایه زیرساخت از لایه های دیگر پشتیبانی می کند پیاده سازی انتزاعات (abstractions)و...
این لایه شامل مواردی مانند تماس های API به API های شخص ثالث است.
این لایه لایه ای خواهد بود که به سرویس های خارجی مانند پایگاه داده، سیستم های پیام رسانی و سرویس های ایمیل دسترسی دارد.
همان لایه بندی را می توان مانند نمودار زیر نشان داد معروف به Clean Architecture یا گاهی Onion Architecture :
در این معماری هر لایه، به لایه ی داخلی تر وابسته بوده و به آن دسترسی دارد. لایه های داخلی هیچ Reference ای به لایه های بالاتر ندارند. هرچند می توانند با ارسال Event آن ها را از وقوع رویدادی باخبر کنند. همانطور که در شکل مشاهده می کنید لایه ی Entity، داخلی ترین لایه بوده و به هیچ لایه ی بیرونی وابستگی ندارد.
بیشترین تمرکز طراحی دامنه محور لایه های Domain و Application می باشد و لایه های Presentation و Infrastructure را به نوعی نادیده می گیرد اما این به معنای کم اهمیت بودن آن نیست، آنها بسیار مهم هستند.
در پست های بعدی یک پیاده سازی کامل در قالب یک پروژه فرضی را با هم شروع خواهیم کرد.
بیشتر بخوانید : نقشه راه توسعه دهندگان Asp.NET Core
https://zarinp.al/farshidazizi