ارتباطات #

با اطمینان می تونیم بگیم که تقریباً تمام پروژه‌های نرم‌افزاری نیاز به همکاری افراد در نقش‌های مختلف دارن: متخصص دامنه، مالکان محصول، مهندسان، طراحان رابط و تجربه کاربری، مدیران پروژه، تسترها، تحلیلگران و سایر افراد. مثل هر تلاش تیمیه دیگه ای، نتیجه ی کار کاملا به اندازه ی اینکه چقدر تمام این افراد می‌تونن با هم کار کنن، وابسته است. به عنوان مثال، آیا همه افراد موافقن که چه مساله ای در حال حل شدن هست؟ در مورد راه حلی که در حال ساختنش هستن چی؟ آیا افراد دارای فرضیات متفاوت و یا متضادی درباره نیازمندی‌های کارکردی و غیرکارکردی یه سیستم هستن؟ موافقت و هم راستا بودن در تمام فرایند مرتبط با پروژه، برای موفقیت پروژه ضروری است. تحقیقات در زمینه علت‌های شکست پروژه‌های نرم‌افزاری نشون داده که ارتباط مؤثر برای به اشتراک گذاری دانش و موفقیت پروژه ضروریه. با این حال، با وجود اهمیت این موضوع، ارتباط مؤثر به ندرت در پروژه‌های نرم‌افزار مشاهده می‌شه. اغلب، ساید بیزینس و مهندس ها کمتر با یکدیگر تعامل مستقیم دارن. به جای این ارتباطات موثر، دانش دامنه از متخصصان دامنه به مهندسان از طریق افرادی انتقال پیدا میکنه که نقش واسطه یا “مترجم” رو بازی می‌کنن، از جمله تحلیلگرها و مدیران سیستم/کسب‌وکار، مالکان محصول و مدیران پروژه. جریان معمول به اشتراک گذاری دانش به وسیله این افراد در شکل 2-1 نمایش داده شده. ( این نکته رو هم بگم که ما نمیگیم که این نقش ها بی فایده هستند، ما در نحوه ی انتقال این دانش داریم صحبت میکنیم.)

![[Figure 2-1.png]] شکل 2-1. جریان به اشتراک گذاری دانش در یک پروژه نرم‌افزار

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

![[Figure 2-1 1.png]] شکل 2-2. تبدیل‌ مدل ها

پیام یا دانش دامنه، اغلب تحریف می‌شه و این اطلاعات منجر به پیاده‌سازی اشتباه توسط مهندسان نرم‌افزار می‌شود، یا حتی منجر به پیاده سازی درست، اما برای مسائل اشتباه می شه. در هر دو حالت، نتیجه یکسانه: یک پروژه نرم‌افزاری ناموفق.

Domain-Driven Design (DDD) می گه که راه بهتری برای انتقال دانش از متخصصان دامنه به مهندسان نرم‌افزار وجود داره: استفاده از یک زبان فراگیر (ubiquitous language).