فلسفه طراحی دامنه محور برای اولین بار در سال ۲۰۰۳، در کتابی با عنوان Domain-Driven Design، توسط Eric Evans مطرح گردید و در آن از لزوم تمرکز بر روی پیچیدگی ذاتی دامنه فعالیت نرم افزار (Domain) صحبت شد. این طراحی به عنوان یک متدولوژی، راهکارهایی را فراهم می‌کند تا توسعه مدل مدنظر منجر به تولید سیستمی شود که نیازهای حوزه فعالیت سیستم را برآورده کرده و در برابر تغییر شکل فرآیندهای سیستم منعطف باشد. برای رسیدن به این منظور، نرم‌افزار باید کاملا با دامنه فعالیت سیستمی که برایش طراحی شده است هماهنگ باشد، در غیر این صورت با تغییر جزئی در سیستم، نرم‌افزار شما دچار آسیب و آشفتگی‌های فراوان خواهد شد.
خب چگونه می‌توان یک نرم‌افزار را تا حد مطلوبی با دامنه هماهنگ کرد؟ بهترین روش، طراحی نرم‌افزاری است که انعکاسی از دامنه فعالیت سیستم باشد. نرم‌افزار نیاز دارد تا مفاهیم اصلی سیستم را با المان‌های آن ترکیب کند و درکی کامل از ارتباط بین آن‌ها داشته باشد. در واقع نرم‌افزار باید مدلی از دامنه فعالیت سیستم باشد. به همین دلیل تاکید طراحی دامنه محور بر شناخت مسائل حوزه فعالیت سیستم است تا مدلی انتزاعی از آن بوجود بیاید (Domain model) که سپس می‌توان با تکنولوژی‌های مشخصی آن را پیاده‌سازی کرد. در اینجا منظور از Domain model، فقط نمودار و یا مجموعه‌ای از نمودارها برای توضیح دامنه نیست، بلکه این مدل شامل مجموعه‌ای از مفاهیم، قوانین و رفتارهاست که در کد نمایان می‌شوند و با تغییر رفتار و فرآیندهای سیستم ممکن است تغییر یابند. مدل برای ما نماینده‌ای از دامنه فعالیت سیستم است و یکی از اصلی‌ترین المان‌ها در فرآیند طراحی و توسعه است. ما به مدل نیاز داریم تا بتوانیم پیچیدگی‌های سیستم را درک کنیم و با آن تعامل داشته باشیم. در واقع تمام ذهنیت ما در مورد دامنه در مدل ترکیب شده است.
داشتن مدلی کامل، امری ضروری است ولی باید بتوان این مدل را به صورتی ارائه کرد تا علاوه بر طراحان و توسعه‌دهندگان نرم‌افزار، افراد متخصص در حوزه فعالیت سیستم نیز بتوانند آن را درک کرده و با آن کار کنند. در فرآیند تولید نرم‌افزار افراد مختلفی با تخصص‌های متفاوت مشارکت دارند و نیاز است تا بتوانند اطلاعات و دانش خود را با بقیه به اشتراک بگذارند. راه‌های زیادی برای انجام این مهم وجود دارد. می‌توان از نمودارها و تصاویر استفاده کرد و یا از افراد خواست تا دیدگاه‌های خود را در مورد دامنه مطرح کنند. اما یکی دیگر از راه‌حل‌ها استفاده از یک زبان مشترک برای بیان مسائل مربوط به دامنه فعالیت سیستم است. در واقع ایده داشتن یک مدل و زبان مشترک این است تا افرادی با تخصص و دیدگاه‌های متفاوت بتوانند با یکدیگر ارتباط برقرار کنند. در اصطلاح به این زبان مشترک Ubiquitous Language گفته می‌شود. این زبان مشترک تمامی بخش‌های طراحی را به هم مرتبط می‌کند و به تیم طراحی یک دیدگاهی می‌دهد تا بتوانند بهتر کار کنند. برخی از پروژه‌های بزرگ ممکن است هفته‌ها و یا ماه‌ها طول بکشند تا شکل گیرند. در خلال طراحی ممکن است برخی از فرضیات و مفاهیم اولیه نادرست تشخیص داده شوند و یا بعضی از مسائل درنظر گرفته نشده اضافه شوند. تمام این مسائل بدون داشتن یک زبان مشترک غیرممکن است.
خب چگونه می‌توان یک زبان مشترک ایجاد کرد؟ برای فهم این موضوع بگذارید تا فرآیند شکل‌گیری یک مدل و زبان مشترک را با یک مثال پیگیری کنیم. فرض کنید نیاز است تا نرم‌افزاری برای کنترل پرواز هواپیماها تولید شود. می‌توان گفت مدل اولیه برای این سیستم از دید یک توسعه‌دهنده چیزی شبیه به شکل زیر است:
هواپیما از یک مبدا شروع به حرکت می‌کند و به مقصد می‌رسد. بدون شک این مدل اولیه ناقص است و توسعه‌دهنده برای درک بهتر فرآیند، باید با یک متخصص در این حوزه مشورت کند. در اینجا شکل‌گیری زبان مشترک بین یک توسعه‌دهنده نرم‌افزار و یک متخصص در حوزه مانیتورینگ ترافیک هوایی را به صورت یک گفتگوی دوطرفه شرح می‌دهیم و خواهیم دید مدل اولیه چگونه در حین گفتگو کامل‌تر شده و نواقص آن برطرف می‌شود. در ضمن به تدریج زبان مشترک بین طرفین نیز با شناخته شدن مفاهیم کلیدی شکل می‌گیرد.
می‌خوای یه فروشگاه به وسعت اینترنت داشته باشی؟
ما حرفه‌ای‌ترین فروشگاه آنلاین رو برات طراحی می‌کنیم.
توسعه‌دهنده: ما می‌خواهیم ترافیک هوایی را مانیتور کنیم. از کجا باید شروع کنیم؟
متخصص: اجازه بده از مسائل پایه‌ای شروع کنیم. تمام ترافیک موجود به دلیل وجود هواپیماهاست. هر هواپیما از یک مبدا بلند می‌شود و در یک مقصد فرود میاید.
توسعه‌دهنده: چه راحت. وقتی هواپیمایی پرواز می‌کند می‌تواند در هر مسیری که خلبان بخواهد حرکت کند؟ آیا این به عهده خلبان است تا مسیر پرواز هواپیما را انتخاب کند؟
متخصص: نه، اصلا. خلبانان یک مسیر پروازی (Route) را دریافت می‌کنند که باید آن را دنبال کنند و تا حد ممکن از آن خارج نشوند.
توسعه دهنده: من دارم به مسیر پرواز به عنوان یک مسیر سه بعدی در فضا فکر می‌کنم. اگر ما از یک سیستم کارتزین برای مختصات استفاده کنیم، مسیر پرواز مجموعه‌ای از این مختصات سه بعدی خواهد بود. به همین دلیل مبدا و مقصد پرواز نیز خود یکی از این نقاط (Fix) خواهند بود و نیاز نیست تا آن‌ها را به عنوان مفاهیمی متفاوت در نظر بگیریم. هواپیما به مقصد می‌رسد همانطور که به هر نقطه‌ی دیگری می‌رسد.
متخصص: من همچین فکری نمی‌کنم. ما مسیر پرواز را به این صورت نمی‌بینیم. مسیر پرواز در واقع یک تصویری از حرکت هواپیما روی زمین است. مسیر پرواز مجموعه‌ای از نقاط روی زمین است که با طول و عرض جغرافیایی محاسبه می‌شود.
توسعه دهنده: خب، پس می‌توانیم هر کدام از این نقاط دو بعدی را به عنوان یک ثابت درنظر بگیریم زیرا هر کدام نمایانگر یه نقطه ثابت بر روی زمین هستند. مسیر پرواز نیز مجموعه‌ای از این نقاط دو بعدی خواهد بود. خب، هواپیما باید مسیر پرواز را دنبال کند ولی آیا به این معنی است که می‌تواند در هر ارتفاعی پرواز کند؟
متخصص: خیر. ارتفاعی که هواپیما در هر لحظه باید در آن باشد در برنامه پرواز (Flight plan) مشخص شده است.
توسعه‌دهنده: برنامه پرواز. این دیگه چیه؟
متخصص: قبل از ترک فرودگاه، خلبانان برنامه پرواز را دریافت می‌کنند که شامل همه اطلاعات در مورد پرواز، مسیر پرواز، ارتفاع، سرعت، نوع هواپیما و حتی خدمه هواپیماست.
توسعه‌دهنده: به نظر برنامه پرواز موضوع مهمی است و باید در مدل در نظر گرفته شود.
توسعه‌دهنده: خیلی بهتر شد. الان وقتی به مدل نگاه می‌کنم، متوجه می‌شم که وقتی یک ترافیک هوایی رو مانیتور می‌کنیم، نباید روی خود هواپیماها تمرکز کنیم که سفید هستند یا آبی و یا بوئینگ هستند یا ایرباس. باید به پرواز توجه کنیم؛ چیزی که باید مانیتور و اندازه‌گیری شود.
تعامل و گفتگو بین این دو متخصص در دو حوزه متفاوت حول یک مدل، علاوه بر تکمیل مدل، کم کم باعث بوجود آمدن زبانی مشترک بین آن‌ها شد. حالا کلماتی مانند برنامه پرواز (Flight plan)، مسیر پرواز (Route) و یا نقاط مسیر (Fix) برای هر دو معانی یکسان و مشخصی دارد. این دقیقا همان زبان مشترک است. همچنین می‌توان دید چگونه همین زبان مشترک روی مدل نیز تاثیر می‌گذارد.
مباحث مطرح شده در مورد طراحی دامنه محور بسیار گسترده بوده و در سال‌های اخیر به شدت مورد توجه قرار گرفته است. در این مقاله سعی شد تا با مفاهیم اولیه و کلیدی این رویکرد نظیر دامنه فعالیت سیستم (Domain)، مدل انتزاعی دامنه (Domain model) و همچنین زبان مشترک (Ubiquitous language) آشنا شویم. در نهایت باید به این نکته توجه کرد که طراحی دامنه محور بیشتر برای پروژه‌های سازمانی و بزرگ مورد استفاده قرار می‌گیرد و به دلیل هزینه بالای تحلیل، طراحی و مدل‌سازی برای پروژه‌های کوچک توصیه نمی‌شود.