پیشگفتار #
مهندسی نرم افزار کار سخت و طاقت فرسایی است. برای اینکه در این حوزه موفق باشیم، ما باید به صورت مستمر موضوعات جدیدی را یاد بگیریم. چه یه زبان برنامه نویسی جدید باشه، یه تکنولوژی جدید و یا یه فریمورک جدید. اگرچه یادگیری یه فریمورک جدید جاوا اسکریپت و یا فریمورکی در دات نت و یا جاوا و یا هر زبان دیگه ای در طول یک هفته برای ما کار چندان پیچیده ای نباشد، اما درک عمیقی از یک دامنه کسب و کار میتونه برامون خیلی چالش بزرگی بحساب بیاد.
این چیز عجیبی نیست که ما چندین و چند نرم افزار برای دامنه های مختلفی از کسب و کار ها را در طول مسیر شغلیمون طراحی و توسعه داده ایم، کسب کارهایی از جنس سیستم های مالی، سیستم های پزشکی، و یا سیستم های خرید و فروش آنلاین، مارکتینگ و کلی سیستم های دیگه.
در واقع از یک نگاه این تفاوت اصلی شغل ما با دیگر شغل هاست، که ما بایستی این همه دامنه کسب و کار رو یادبگیریم و براشون نرم افزار تولید کنیم، و برای خیلی از افرادی که در حوزه های تخصصی دیگه ای مشغول به کار هستند این میتونه براشون یه سورپرایز بزرگ باشه.
اما عدم درک دقیق از حوزه کسب و کار، منجر به توسعه ناکارآمد نرم‌افزارهای کسب و کار می‌شود. متأسفانه، این موضوع بسیار بسیار شایع است. تقریباً 70٪ از پروژه‌های نرم‌افزاری بموقع و با بودجه‌ی از قبل تعیین شده و یا مطابق با نیازهای مشتری تحویل داده نمی‌شوند. به عبارت دیگر، اکثریت قابل توجهی از پروژه‌های نرم‌افزاری شکست میخورند. این مسئله به حدی عمیق و گسترده است که حتی یک اصطلاح برای آن وجود دارد: بحران نرم‌افزار.
اصطلاح “بحران نرم‌افزار” به سال ۱۹۶۸ برمی‌گردد. انتظار می‌رود که در طی این پنجاه سال، وضعیت این بحران بهتر شده باشد و یا ازبین رفته باشد. در این مدت، رویکردها، متودولوژی ها و تخصص‌های مختلفی بوجود آمده اند تا مهندسی نرم‌افزار را به جای درستی هدایت کنند: متدولوژی اجایل، XP،TDD، زبان‌های برنامه‌نویسی سطح بالا، DevOps و خیلی چیز های دیگه. اما متأسفانه، اوضاع تغییر چندانی نکرده و بسیاری از پروژه ها همچنان ناکام می‌مانند و بحران نرم‌افزار همچنان وجود دارد.
تعداد زیادی مطالعه برای بررسی علل شکست پروژه‌ها انجام شده است. اگرچه محققان نتوانسته‌اند یک علت دقیق را مشخص کنند، اما بیشتر آنها یک موضوع مشترک را به اشتراک می‌گذارند: ارتباطات.
مشکلات ارتباطی که پیشرفت پروژه‌ها را متوقف می‌کنند، می‌توانند به شکل‌های مختلفی ظاهر شوند؛ به عنوان مثال، نیازمندی‌های نامعلوم، اهداف نامعلوم پروژه، یا هماهنگی ناموثر تیم‌ها در انجام کار. با این حال، در طول سال‌ها تلاش‌هایی برای بهبود ارتباطات درون و بین تیمی انجام داده‌ایم، معرفی فرآیندها و راه های ارتباطی جدید. اما متأسفانه، نرخ موفقیت پروژه‌های ما تغییر چندانی نکرده است. بهتر شده، اما هنوز این مشکلات ارتباطی وجود دارد.
طراحی دامین محور (DDD) پیشنهاد میدهد که از زاویه‌ای متفاوت به علت اصلی شکست پروژه‌های نرم‌افزاری نگاه کنیم. ارتباطات مؤثر و کارا موضوع مرکزی هست که ما میخوایم در این فصل در موردش صحبت کنیم
DDD به دو بخش تاکتیکی و استراتژیک تقسیم می‌شود.
ابزارهای استراتژیک DDD برای تجزیه و تحلیل دامین‌ها و استراتژی‌های کسب‌وکار به کار می‌روند و بین افراد مختلف تیم توسعه یک درک مشترک از کسب‌وکار ارائه میدهد. همچنین از این قسمت دانش دامین کسب‌وکار، برای اتخاذ تصمیمات طراحی در سطح بالا استفاده می‌شود: مانند تجزیه و ریز کردن اجزای کسب و کار و در نهایت ادغام آنها در راستای ایجاد یک الگوی یکپارچه.
در DDD ابزارهای تاکتیکی به جنبه‌های مختلف مشکلات ارتباطی پرداخته و الگوهای تاکتیکی DDD به ما اجازه میدهد تا کد را به گونه‌ای بنویسیم که با دامین کسب‌وکار هماهنگ باشد، اهداف آن را مد نظر داشته باشد و به زبان کسب‌وکار صحبت کند. همچنین الگوها و روش‌های استراتژیک و تاکتیکی DDD طراحی نرم‌افزار را با دامین کسب‌وکار همسان می‌کنند. این همان جایی است که نام این مفهوم از آن آمده است: Domain-Driven Design و یا طراحی نرم افزار حول محور کسب و کار.
طراحی دامنه محور (Domain-driven design یا DDD) این امکان را برای شما فراهم نمیکنه که بتوانید کتابخانه های مختلف رو روی مغزتان مثل فیلم ماتریکس نصب کنید. با این حال، این اصول و رویکردها شما را به یک مهندس نرم‌افزار بهتری تبدیل می‌کنند، حالا چطور شما به یه مهندس بهتری تبدیل میشوید:
با ساده سازی فرایند های درک دامنه‌های کسب‌وکار
هدایت تصمیمات طراحی بر اساس استراتژی کسب‌وکار
همانطور که در فصول بعدی کتاب خواهید دید، ارتباط نزدیک‌تر بین طراحی نرم‌افزار و استراتژی کسب‌وکار،امکان نگهداری و تکامل سیستم به منظور تأمین نیازهای آینده کسب‌وکار را راحتتر میکند و در نتیجه منجر به موفقیت بیشتر پروژه‌های نرم‌افزاری می‌شود.