آموزش DDD. فضای مساله در برابر فضای راه حل

پیشینه آغاز صنعت نرم افزار، به اوایل دهه 1960 میلادی باز میگردد و از آن زمان همیشه در حال پیشرفت و توسعه بوده است. اما از همان اولین سالها، پروژه هایی که دیر به نتیجه می رسیدند یا هزینه های هنگفتی برای تکمیل نیاز داشتند، بعلاوه پروژه های شکست خورده، تعداد بسیار بالایی را به خود اختصاص می دادند و این روند هم اکنون نیز ادامه دارد.

بر اساس گزارشی که در سال 2015 منتشر شده است، پیش بینی شده است که بین سالهای 2011 تا 2015، فقط 22% از پروژه ها با موفقیت به سرانجام رسیده اند. 19% از پروژه ها کاملا شکست خورده اند و مابقی پروژه ها با چالش های مخصوص به خود در حال کشمکش و مبارزه هستند.

در طول 4 دهه، بسیاری از روش های مدیریت پروژه های نرم افزاری ایجاد شدند و توسعه یافتند، اما یا بی اثر بودند یا تاثیر چندانی روی بهبود درصد پروژه های موفق نگذاشتند.

یکی از فاکتورهای حیاتی موثر در موفقیت پروژه ها، شناخت مساله واقعی و تلاش به رفع آن است. منظور از مساله، آن مشکل یا موضوعی است که بخاطر آن، شما یا کارفرما به توسعه یک نرم افزار احساس نیاز کردید و فکر می کنید این نرم افزار قرار است مشکل معین و واضح پیش بینی شده را رفع کند.

این مشکل (شناخت مساله)، دقیقا نقطه ای است که Domain Driven Design در صدد رفع آن است. این اصطلاح اولین بار در سال 2004 توسط Eric Evans در کتاب مشهور Domain-Driven Design: Tackling Complexity in the Heart of Software، به کار برده و تشریح شد. اصلی ترین عامل اقبال عمومی به این مفهوم این است که DDD تشریح می کند که افراد در صنعت IT چگونه می توانند به یک درک صحیح و جامع از نیازهای کاربران دست یابند تا بتواننند نرم افزارهایی توسعه دهند که مشکلات آنها را رفع کند و برای آنها تاثیر گذار باشد.

شناخت مساله

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

فضای مساله و فضای راه حل (Problem Space و Solution Space)

بشریت، مسائل و مشکلاتش را بوسلیه جستجو برای یک راه حل در فضای مساله برطرف می سازد. این فضا، بیانگر حالت های اولیه (initial state) و وضعیت ایده آل(desired state) است، همانطور که وضعیت های میانه ای نیز وجود دارد. این تئوری توسط Allen Newel و Herbert Simon مطرح شد. همچنین این فضا شامل قواعد و شاخصه هایی است که زمینه مساله را تعریف می سازد.در صنعت نرم افزار، افرادی که درگیر مساله هستند، معمولا مشتریان و کاربران هستند.

برای هر مساله، راه حلی وجود دارد. اگر بدرستی در فضای مساله جستجو کنیم، متوجه قدمهای مورد نیاز برای گذار از حالت اولیه به حالت ایده آل خواهیم شد. این فضا را فضای راه حل می گویند.

داستان رایجی که برای تعریف این دو فضا استفاده می شود، داستان نوشتن در فضاست. در دهه 1960، دانشمندان به مساله ای برخوردند که خودکارهای رایج در فضا به علت تفاوت های جاذبه، قابل استفاده نیستند. ناسا چندین میلیون دلار هزینه کرد تا خودکاری متناسب با این شرایط ابداع کند، اما شوروی برای رفع این مشکل، بجای خودکار، از مداد استفاده کرد و بدون صرف زمان و هزینه مشکل را رفع کرد!

اصلا کمیاب و عجیب نیست که تفسیرهای ما از مشکلات موجود در دنیای واقعی اشتباه باشد. به گونه ای که پیچیدگی های غیر لازمی را برای رسیدن به راه حل می افزائیم و سپس مجبور می شویم مشکلاتی را رفع کنیم که اصلا وجود نداشتند!

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

در اینجا شما بُعد دیگری از مساله فضای مشکل/راه حل را می بینید. اگرچه در ظاهر، مساله ساده به نظر می رسید، محدودیت های جدیدی پدیدار شد که بعنوان نیازمندی های عملیاتی، باعث شد راه حل، پیچیده تر از چیزی که در ابتدا به نظر می رسید شود.

پریدن به سمت راه حل بسیار آسان است. مخصوصا برای ما که تجربه فراوانی در حل مشکلات در کدها یا حرفه خود داریم. تفکر در مورد راه حل، مانع از تفکر مغز ما در مورد خود مشکل می شود. بجای تفکر در مورد مشکل، ما در راه حلی که در ابتدا به ذهنمان خطور کرده غرق می شویم که باعث ایجاد مراتب بیشتری از جزئیات می شود و در نهایت به این نتیجه می رسیم که راه حل ما بهترین راه حل ممکن برای حل آن مشکل معین است.

پس جنبه دیگری که در جستجوی راه حل برای مساله بوجود می آید، خطر ثابت ماندن (قفلی زدن!) در اولین راه حلی است که به ذهنمان خطور کرده. این راه حل معمولا صرفا بدلیل تجارب شخصی ما در حل مشکلات قبلی توسط مغز ما انتخاب شده است، نه به این خاطر که بهترین راه حل ممکن است!

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

نیازمندی ها، چه مشکلی با ما دارند؟!

معمولا توسعه دهندگان ارتباط کمی با کسی که بدنبال حل واقعی مشکلش هست دارند. معمولا افراد دیگری مانند تحلیل گرها، آنالیزر های کسب و کار یا مدیر پروژه ها با مشتریان صحبت می کنند و خروجی مکالماتشان را در قالب نیازمندی های فنی و عملیاتی در اختیار تیم توسعه دهنده قرار می دهند. این نیازمندی ها به اشکال گوناگونی در اختیار توسعه دهندگان قرار می گیرند. یا به صورت یک دایکیومنت بلند بالا به نام سند مشخصات مورد نیاز (requirements specifications) یا بصورت منعطف تر (agile) در قالب یوزر استوری ها.

مثال زیر را در نظر بگیرید:

هر روز، سیستم باید برای هر هتل، یک لیست از مهمان هایی که انتظار می رود در آن روز ورود و خروج کنند، تولید کند.

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

در مقابل، توسط یوزر استوری ها، بینش بیشتری در مورد آنچه کاربران نیاز دارند بدست می آوریم. بیایید یک یوزر استوری واقعی در زندگی را مرور کنیم:

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

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

اصلا به این فکر نکنید که صرف زمان برای درک نیازمندی های کاربر، کاری عبث و اتلاف وقت است. شناخت این نیازمندی ها که تقریبا همیشه بیانگر درکی درست از مشکل واقعی از زاویه دید کاربر است، امری حیاتی است. عدم درک مشکل واقعی کاربر، باعث صرف زمان و هزینه بیشتر و بیشتر و شاید ایجاد فیچرهایی با کیفیت بالا می شود، اما شاید در جهتی متفاوت از رفع مشکل واقعی کاربر!

روش های agile و lean مشوق خوبی برای ارتباط مستقیم و بیشتر بین توسعه دهندگان و کاربران نهایی هستند. درک مشترک مسائل بین همه سهامداران، توسعه دهندگان و کاربران نهایی و تست کنندگان، یافتن راه حل ها به کمک یکدیگر، از بین بردن فرضیات غلط و ساخت پروتوتایپ هایی برای کاربران نهایی، همه این موارد می تواند منتج به دستیابی به یک تیم موفق و در نتیجه یک پروژه موفق می گردد.

در بخش بعدی خواهیم دید که این مفاهیم ارتباط نزدیکی با DDD دارند!