فلسفه طراحی دامنه محور برای اولین بار در سال ۲۰۰۳، در کتابی با عنوان Domain-Driven Design، توسط Eric Evans مطرح گردید و در آن از لزوم تمرکز بر روی پیچیدگی ذاتی دامنه فعالیت نرم افزار (Domain) صحبت شد. این طراحی به عنوان یک متدولوژی، راهکارهایی را فراهم می‌کند تا توسعه مدل مدنظر منجر به تولید سیستمی شود که نیازهای حوزه فعالیت سیستم را برآورده کرده و در برابر تغییر شکل فرآیندهای سیستم منعطف باشد. برای رسیدن به این منظور، نرم‌افزار باید کاملا با دامنه فعالیت سیستمی که برایش طراحی شده است هماهنگ باشد، در غیر این صورت با تغییر جزئی در سیستم، نرم‌افزار شما دچار آسیب و آشفتگی‌های فراوان خواهد شد.

خب چگونه می‌توان یک نرم‌افزار را تا حد مطلوبی با دامنه هماهنگ کرد؟

بهترین روش، طراحی نرم‌افزاری است که انعکاسی از دامنه فعالیت سیستم باشد. نرم‌افزار نیاز دارد تا مفاهیم اصلی سیستم را با المان‌های آن ترکیب کند و درکی کامل از ارتباط بین آن‌ها داشته باشد. در واقع نرم‌افزار باید مدلی از دامنه فعالیت سیستم باشد. به همین دلیل تاکید طراحی دامنه محور بر شناخت مسائل حوزه فعالیت سیستم است تا مدلی انتزاعی از آن بوجود بیاید (Domain model) که سپس می‌توان با تکنولوژی‌های مشخصی آن را پیاده‌سازی کرد. در اینجا منظور از Domain model، فقط نمودار و یا مجموعه‌ای از نمودارها برای توضیح دامنه نیست، بلکه این مدل شامل مجموعه‌ای از مفاهیم، قوانین و رفتارهاست که در کد نمایان می‌شوند و با تغییر رفتار و فرآیندهای سیستم ممکن است تغییر یابند. مدل برای ما نماینده‌ای از دامنه فعالیت سیستم است و یکی از اصلی‌ترین المان‌ها در فرآیند طراحی و توسعه است. ما به مدل نیاز داریم تا بتوانیم پیچیدگی‌های سیستم را درک کنیم و با آن تعامل داشته باشیم. در واقع تمام ذهنیت ما در مورد دامنه در مدل ترکیب شده است.

داشتن مدلی کامل، امری ضروری است ولی باید بتوان این مدل را به صورتی ارائه کرد تا علاوه بر طراحان و توسعه‌دهندگان نرم‌افزار، افراد متخصص در حوزه فعالیت سیستم نیز بتوانند آن را درک کرده و با آن کار کنند. در فرآیند تولید نرم‌افزار افراد مختلفی با تخصص‌های متفاوت مشارکت دارند و نیاز است تا بتوانند اطلاعات و دانش خود را با بقیه به اشتراک بگذارند. راه‌های زیادی برای انجام این مهم وجود دارد. می‌توان از نمودارها و تصاویر استفاده کرد و یا از افراد خواست تا دیدگاه‌های خود را در مورد دامنه مطرح کنند. اما یکی دیگر از راه‌حل‌ها استفاده از یک زبان مشترک برای بیان مسائل مربوط به دامنه فعالیت سیستم است. در واقع ایده داشتن یک مدل و زبان مشترک این است تا افرادی با تخصص و دیدگاه‌های متفاوت بتوانند با یکدیگر ارتباط برقرار کنند. در اصطلاح به این زبان مشترک Ubiquitous Language گفته می‌شود. این زبان مشترک تمامی بخش‌های طراحی را به هم مرتبط می‌کند و به تیم طراحی یک دیدگاهی می‌دهد تا بتوانند بهتر کار کنند. برخی از پروژه‌های بزرگ ممکن است هفته‌ها و یا ماه‌ها طول بکشند تا شکل گیرند. در خلال طراحی ممکن است برخی از فرضیات و مفاهیم اولیه نادرست تشخیص داده شوند و یا بعضی از مسائل درنظر گرفته نشده اضافه شوند. تمام این مسائل بدون داشتن یک زبان مشترک غیرممکن است.

خب چگونه می‌توان یک زبان مشترک ایجاد کرد؟

برای فهم این موضوع بگذارید تا فرآیند شکل‌گیری یک مدل و زبان مشترک را با یک مثال پیگیری کنیم. فرض کنید نیاز است تا نرم‌افزاری برای کنترل پرواز هواپیماها تولید شود. می‌توان گفت مدل اولیه برای این سیستم از دید یک توسعه‌دهنده چیزی شبیه به شکل زیر است:

طراحی دامنه محور

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

ارسال یک نظر برای این صفحه