تبدیل از CRUD به Task-base UI

تقریبا ۶ سال پیش زمانی که در حال توسعه یک نرم‌افزار تحریریه خبر بودم، جلسات زیادی با دوستان خبرنگار داشتم و زمانی‌که نرم‌افزارهای موجود و خواسته‌های دوستان خبرنگار را با هم مقایسه کردم به این نتیجه رسیدم که شاید نحوه ارائه خروجی‌های نرم افزار بزرگترین ایراد نرم افزار‌های فعلی است و در نتیجه تلاش کردم راهکاری پیدا کنم برای اینکه نرم‌افزار بهتر و ساده‌تری آماده کنم. بعد از مدتی گشت و گذار در وب با مفهموم Task-base UI یا در ادبیات مایکروسافت Inductive User Interface آشنا شدم و سعی کردم ساختار خروجی برنامه‌ی جدید را با روش پیشنهادی پیاده‌سازی کنم. در این مطلب قصد داریم با اصول کلی Task-base UI یا Inductive User Interface آشنا شویم. به طور کلی در این مطلب با هم بررسی می‌کنیم Task base UI چه تفاوتی با CRUD base UI دارد و چگونه پیاده سازی Task-base UI که از این به بعد با عنوان اختصاری TBUI می‌شناسیم، طراحی اپلیکیشن و APIهای ما را تحت تاثیر قرار می‌دهد.

مقدمه

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

• من: “چگونه یک مطلب را منتشر می‌کنید؟”
• خبرنگار: “به صفحه ویرایش خبر می‌رویم و وضعیت خبر را به منتشر شده تغییر می‌دهیم و خبر را ذخیره می‌کنیم.”.
• من :”در صورتی که بخواهید خبری را به اشتراک بگذاری چه کاری انجام می‌دهید؟”
• خبرنگار: “به صفحه ویرایش خبر می‌رویم و فیلد مشترکین را پر میکنیم و دکمه ذخیره را میزنیم.”
• من: ” در صورت نیاز داشته باشید خبری را کوک کنید چه کار می‌کنید؟”
• خبرنگار: ” به صفحه ویرایش خبر می‌رویم و فیلد زمان انتشار را انتخاب می‌کنیم و زمان را به صورت دلخواه تغییر داده و دکمه ذخیره را میزنیم.”

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

• ثبت خبر
• ویرایش خبر

اما برای رفع این مشکل چه کاری باید انجام دهیم؟

تغییر در اپلیکیشن: معرفی Commandها

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

• انتشار خبر: داده‌های مورد نیاز فقط شناسه خبر که در این Command ابتدا خبر پیدا می‌شود و وضعیت آن به منتشر شده تغییر می‌یابد.
• تعلیق خبر: داده‌های مورد نیاز در این Commandهم فقط شناسه خبر است و این بار به جای تغییر وضیعت به منتشر شده وضعیت آن را به معلق شده تغییر می‌دهیم.
• کوک خبر: داده‌های مورد نیاز شناسه خبر و زمان مورد انتظار و در این Command، ابتدا خبر یافت شده و سپس زمان انتشار آن به زمان ورود تغییر می‌یابد و اطلاعات ذخیره می‌شود.

هنگام پیاده سازی Commandها نکته خاصی وجود ندارد و به روش‌های مختلفی این کار انجام می‌شود. فقط هنگام نام گذاری باید دقت شود که نام Commandها باید در حالت دستوری باشد که هنگام مطالعه کد کاملا جنبه عملگرا و وظیفه‌ محور بودن این کلاس‌ها مشهود باشد.
نکته قابل تامل دیگر در این زمینه این است که Commandها باید با ادبیات دامنه نام گذاری شوند. مثلا در دامنه خبر “تغییر وضعیت” نداریم بلکه “منتشر کردن” و “معلق کردن” داریم. در ادبیات حوزه بانکی “ساخت حساب” نداریم بلکه “افتتاح حساب” داریم و اگر به دامنه‌هایی که میشناسید مراجعه کنید موارد بسیاری را خواهید یافت.
به عنوان آخرین نکته در این قسمت هم تاکید می‌کنم که در پیاده سازی این روش زیاده‌روی نکنید. به هرحال هر نرم افزاری برای اینکه عملکردی صحیح داشته باشد نیاز به داده‌هایی دارد که به عنوان داده‌های پایه وجود دارند و برای این داده‌ها نیازی به پیاده سازی به صورت command وجود ندارد.

تغییر در رابط کاربری: پیاده سازی Task-Base UI

بعد از اتمام پیاده سازی APIهای برنامه، نوبت به تغییر در ساختار UI می‌رسد. حال به جای اینکه تعدادی صفحات ساده CRUD داشته باشیم، باید صفحاتی تخصصی برای پیاده سازی ادبیات دامنه طراحی و پیاده سازی کنیم. در ادامه بررسی مثال تحریریه خبر صفحاتی مانند مثال زیر خواهیم داشت.
انتشار خبر: یک صفحه که اطلاعات کاملی از خبر را نمایش می‌دهد با یک دکمه بزرگ سبز رنگ که روی آن نوشته شده “انتشار خبر”.تعلیق خبر: در یک صفحه لیستی از اخبار نمایش داده می‌شود که اصطلاحا کارتابل خبر نام دارد. در این لیست، روبروی هر خبر یک دکمه قرمز رنگ وجود دارد که روی آن عبارت تعلیق خبر نوشته شده است.کوک خبر: جلوی هر خبر در صفحه کارتابل تعدادی دکمه وجود دارد که اعمال مختلف مربوط به خبر را لیست کرده که یکی از آن‌ها کوک خبر است. با انتخاب کوک خبر به صفحه دیگر هدایت می‌شویم که در آن یک DateTimePicker وجود دارد و یک دکمه با عنوان کوک خبر.

دستاورد‌های این تغییرات

اگر به روش CRUD اپلیکیشن خود را طراحی کنیم، چیزی که در متن مستند مایکروسافت به آن Deductive User Interface گفته شده است با سه مشکل عمده مواجه خواهیم بود که با پیاده سازی TBUI این مشکلات حل خواهد شد.

• کاربران مدل کامل و دقیقی از کسب کار را در ذهن خود ندارند.در مدل Deductive ما به عنوان طراح نرم‌افزار امیدوار هستیم که کاربر مدلی که ما در ذهن خود طراحی کردیم را کامل بداند و درک کنند. این همان مشکلی است که معمولا توسعه دهندگان را دیوانه می‌کند. بیایید با خودمان رو راست باشیم. تا به حال چند بار هنگامی که در مورد عملکرد نرم افزار از شما سوال شده است در دل خود یا با همکاران خود گفته‌اید چه کاربران ابلهی از نرم افزار ما استفاده می‌کند؟ یا ببین برای چه خنگ‌هایی برنامه می‌نویسیم.

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

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

جمع بندی

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