طراحی دامنه محور (DDD) حدود 15 سال است که وجود دارد. این نام توسط اریک ایوانز در کتاب وی به نام "طراحی دامنه محور: مقابله با پیچیدگی در قلب نرم افزار" ابداع شد.
طراحی دامنه محور (DDD) رویکردی برای توسعه نرم افزار برای نیازهای پیچیده با اتصال عمیق پیاده سازی به یک مدل در حال تکامل از مفاهیم اصلی کسب و کار است. در این مفهوم ساختار و زبان کد نرم افزار (نام کلاس ها، روش های کلاس، متغیرهای کلاس) باید با دامنه تجاری مطابقت داشته باشد. به عنوان مثال، اگر نرم افزاری برنامه های وام را پردازش کند، ممکن است کلاس هایی مانند LoanApplication و Customerو روش هایی مانند AcceptOffer و Withdraw داشته باشد.
فرض های اولیه این معماری موارد زیر است:
معماری DDD یک فناوری نیست، بلکه اصطلاحات، شیوه ها و اصول را برای حمایت از تصمیم گیری در حوزه های تجاری پیچیده معرفی می‌کند. اگر پیچیدگی دامنه زودتر و به درستی در طراحی برنامه مورد توجه قرار نگیرد، بهترین فناوری به ایجاد سیستمی که قابل نگهداری، قابل گسترش و غیره باشد کمکی نخواهد کرد.
علاوه بر این، DDD یک زبان مشترک و فراگیر را معرفی می‌کند که می تواند همکاری تیم‌ها را بهبود بخشد تا ارتباط میان افراد با پیشینه ها و دیدگاه های مختلف سهل گردد. به عنوان مثال، کارشناسان حوزه عمل را درک می کنند و طراح سیستم فناوری را درک می کند.
در زمینه Microservice Architectures، توسعه دهندگان و معماران به دنبال روش یا ابزاری برای تعریف محدوده و اندازه هر Microserviceبودند. تعیین این مرز آسان نیست و اگر تصمیمات اساسی در مورد چگونگی "برش" اشتباه باشد، سیستم به سرعت به اصطلاح معروف "big ball of mud" تبدیل خواهد شد. DDD مفهوم زمینه های محدود را معرفی کرد تا به پاسخگویی به سوالات کمک کند. اما DDD حاوی مفاهیم و اصول بیشتری است که به ایجاد سیستم های قوی و قابل نگهداری کمک می‌کند. مایکل پلود در مورد اینکه چگونه اصول DDDمی تواند به ایجاد میکروسرویس های خوب کمک کند، مطالبی را ارائه داده است.
مروزه سیستم های مدرن اغلب توزیع شده و واکندار اند و از پیام رسانی ناهمزمان استفاده می‌کنند. چنین معماری هایی مستقیماً به چالش هایی مانند مدیریت پیام های متعدد یا تحویل خارج از دستور منجر می‌شود. در مقاله‌ای وان ورنون نشان می‌دهد که چگونه DDDمی‌تواند به مدیریت این عدم قطعیت از طریق استفاده از مدل‌سازی خوب کمک کند.
منبع یابی رویداد (event sourcing) رویکردی برای ذخیره داده‌ها است و فقط از دستورات SQL INSERTو SELECT استفاده می کند. اگرچه منبع یابی رویداد بخشی از DDDنیست اما هر دو مفهوم به خوبی یکدیگر را تکمیل می کنند.
الگوی طراحی CQRSجداسازی سمت نوشتن از سمت خوانده شده یک برنامه کاربردی را توصیف می کند. CQRSو DDD لزوماً به یکدیگر تعلق ندارند، بلکه به خوبی یکدیگر را تکمیل می کنند، به همین دلیل است که ترکیب آنها اغلب در عمل مورد استفاده قرار می گیرد.
اگرچه این مفاهیم به خودی خود ایستاده اند و می توان آنها را به طور جداگانه به کار برد، اما می توان مشاهده کرد که هر سه با هم اغلب با هم ترکیب می شوند.
مفاهیم DDDحتی از روش چابک به خوبی پشتیبانی می کنند. بسیاری از رهبران فکری چابک وجود دارند که از DDD حمایت می کنند به عنوان مثال، مارتین فاولر در صفحه وب خود یا کنت بک در پشت جلد کتاب ایوانز در مورد DDD صحبت می‌کند. "اگر می خواهید کارها را درست انجام دهید، گاهی باید کمی بیشتر در مورد آن فکر کنید. فقط در آن عجله نکنید، به خصوص اگر از مفاهیم پیچیده ای مانند CQRS و Event Sourcing استفاده کنید."
از جمله ابزارهای این مفهوم میتوان موارد زیر را نام برد.
ابزار Actifsource، یک پلاگین برای Eclipse که توسعه نرم افزار را با ترکیب DDDبا مهندسی مدل محور و تولید کد امکان پذیر می‌کند.
ابزار CubicWeb، یک چارچوب وب معنایی منبع باز که به طور کامل توسط یک مدل داده هدایت می شود.
ابزار OpenMDX، یک چارچوب MDA منبع باز، مبتنی بر جاوا با پشتیبانی از Java SE، Java EE و .NET
ابزار Restful Objects، استانداردی برای نگاشت یک API Restful بر روی یک مدل شی دامنه است.
«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»
