گاهی اوقات متوجه می شوید که نقض قوانین باعث صرفه جویی در وقت شما می شود اما در کوتاه مدت. با این حال، در کوتاه مدت شما زمان ذخیره شده به ارمغان خواهید آورد. اما در میان مدت و بلند مدت زمان بسیار بیشتری را از دست خواهید داد! codebase شما پیچیده و نگهداری آن سختر می شود. برنامه های تجاری فقط به این دلیل که شما دیگر نمی توانید آن را به سادگی نگهداری کنید و یا توسعه دهید دوباره نوشته می شوند. اگر از قوانین، اصول، الگوها و بهترین شیوه ها پیروی کنید، codebase شما ساده تر و راحت تر نگهداری می شود و در نتیجه می تواند سریعتر تغییر کند. طراحی دامنه محور ( Domain Driven Design ) چیست؟ طراحی دامنه محور ( DDD ) یک رویکرد برای توسعه نرم افزار با نیازمندیهای پیچیده است. DDD برای دامنه های پیچیده و در مقیاس بزرگ مناسب است و در نهایت به ایجاد یک کد انعطاف پذیر، ماژولار و قابل نگهداری کمک می کند. قبلا در این مختصرا در خصوص اینکه طراحی دامنه محور چیست، چرا به آن نیاز داریم؟ همچنین مزایا و معایب آن صحبت کردیم. پیشنهاد می کنم قبل از مطالعه ادامه این پست حتما آن نگاهی به آن بیاندازید. پیاده سازی DDD به شدت به شی گرایی OOP و متکی است بنابراین درک OOP & واقعا کمک زیادی به شما در پیاده سازی DDD خواهد کرد. لایه ها در DDD و Clean Architecture همانطور که درتصویر بالا ملاحظه می کنید در معماری پروژه های DDD چهار لایه اساسی وجود دارد. این معماری لایه Business Logic را در دو لایه قرار می دهد، لایه Domain ولایه Application ، در حالی که آنها شامل انواع مختلفی از business logic هستند. بیشتر بخوانید: اینجا مرکز سیستم و قلب برنامه است. دامنه بیشتر منطق کسب و کار سیستم را کنترل می کند. این لایه همچنین وظیفه تعریف مفاهیم، رفتارها و قوانین را بر عهده دارد. لایه های باقی مانده آنها را پیاده سازی می کنند. اما قبل از هر چیز و برای پیاده سازی Domain Model نیاز به دانستن مفاهیم و اجزای سازنده آن داریم: Entities ( Value Objects ( Aggregate & Aggregate Root ( Repositories Domain Services Specifications Domain Event Factories لایه Domain باید کاملا از بقیه سیستم جدا باشد. با این حال، چیزی باید مقادیر خاص UI ( query strings POST data , session و غیره) را به اشیاء Domain ترجمه کند. این لایه به عنوان دروازه ای عمل می کند که در آن برنامه ها ( Presentation Layer ) با سیستم تعامل دارند. این لایه اطلاعات جمع آوری شده از تعاملات بین برنامه و کاربران نهایی یا خدمات شخص ثالث ( third - party services ) را پردازش می کند. درخواست‌ها را دریافت می‌کند و قبل از ارسال آن‌ها به دامنه ( Domain ) برای پردازش، ورودی را ت یید ( validates ) می‌کند. لایه Application همچنین پاسخ هایی ( responses ) را به Presentation Layer ارایه می دهد. و به طور موثر دامنه را از بقیه سیستم پنهان کند. و اما مهمترین مفاهیمی که در لایه Application : Application Services Data Transfer Objects ( DTOs ) Unit of Work شامل عناصر UI از جمله pages و components و. لایه زیرساخت از لایه های دیگر پشتیبانی می کند پیاده سازی انتزاعات ( abstractions ) و ادغام ها به کتابخانه و سیستم های شخص ثالث. همان لایه بندی را می توان مانند نمودار زیر نشان داد معروف به Clean Architecture یا گاهی Onion Architecture : در این معماری هر لایه، به لایه ی داخلی تر وابسته بوده و به آن دسترسی دارد. لایه های داخلی هیچ Reference ای به لایه های بالاتر ندارند. هرچند می توانند با ارسال Event آن ها را از وقوع رویدادی باخبر کنند. همانطور که در شکل مشاهده می کنید لایه ی Entity ، داخلی ترین لایه بوده و به هیچ لایه ی بیرونی وابستگی ندارد. این پست در حال تکمیل شدن می باشد.