Domain Driven Design

یک تعریف رسمی برای DDD توسط اریک ایوانز، نویسنده کتاب domain driven design tackling complexity in the heart of software ارائه شده است. به گفته وی:

• هنگامی که یک نرم‌افزار را توسعه می‌دهیم، در درجه اول تمرکز ما نباید روی فناوری باشد، بلکه باید روی کسب‌و‌کار یا هر فعالیت کمکی به دامنه باشد.

• در واقع ما با تلاش برای توسعه مدل‌های آن دامنه و ایجاد متابعت بین نرم‌افزار و دامنه، به این هدف خواهیم رسید. (دامنه، کسب‌وکاری است که قصد حل مشکلات آن را داریم و با توسعه نرم‌افزار مشکلات آن را رفع می‌کنیم. این دامنه می‌تواند هر حوزه کسب‌وکاری مانند حوزه حمل و نقل هوایی، راه آهن، بانک، بیمه و ... باشد.)

طراحی دامنه محور (DDD) روشی برای دید بالا به پایین نرم‌افزار است.

منظور از این جمله چیست؟

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

کل این پروژه می‌تواند یک سرویس باشد. اگر بخواهیم از این لایه بالاتر برویم، به لایه‌ای می‌رسیم که در آن تعداد زیادی سرویس وجود دارد و این سرویس‌ها می‌توانند بخشی از یک زیر دامنه باشند.(برای مثال در حوزه تجارت الکترونیک زیر دامنه‌های مشتری و محصول را داریم.) همه این سرویس‌ها سعی در حل یک مشکل کسب‌وکاری دارند و بخشی از یک دامنه هستند.

همچنین DDD دو نوع ابزار را در اختیار ما قرار می‌دهد:

• ابزارهای طراحی استراتژیک که کمک می‌کند تمام مشکلات مربوط به مدل‌سازی و دامنه نرم‌افزار را حل کنیم.

• ابزارهای طراحی تاکتیکی ک کمک می‌کند تا بخشی از مشکل که در تصویر زیر نمایش داده شده است را حل کنیم.

«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»

[1] https://www.nginx.com/blog/what-is-a-service-mesh/