Event modeling چیست؟ مراحل گام به گام انجام

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

برنامه تان را طوری طراحی کنید که دوست دارید باشد، نه طوری که فعلا کارتان را راه بیندازد!

یکی از عناصر برنامه سازی اصول طراحی دامنه محور (DDD) است. برای کسانی که نمی دانند باید بگویم که DDD یا Domain-Driven Design نام کتابی است که توسط اریک ایوانز در سال 2003 نوشته شده است و متد شناسی طراحی نرم افزار را به تفصیل شرح می دهد. در هسته اش هم، مفاهیم حوزه تجاری را به صورت محصولات نرم افزاری ترسیم می کند.

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

آشنایی با مدل سازی رویدادی

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

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

منابع خارق العاده ای در وب سایت https://eventmodeling.org وجود دارد، اما کاری که امروز می خواستم انجام بدهم این بود که فرآیند پیاده سازی مدل سازی رویدادی را در یک پروژه واقعی تشریح کنم.

مراحل گام به گام

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

اولی، مقاله ای با لینک https://eventmodeling.org/posts/what-is-event-modeling/ در سایت اصلی خود سازنده است. مفاهیم زیادی را به مراحلی که در این مقاله دنبال می کنم اضافه می کند. من توصیه می کنم که حتما قبل از ادامه این مقاله، آن مقاله را بخوانید.

دومیMiro است. Miro.com یک وایت برد مجازی است که به چندین نفر اجازه می دهد تا در یک بورد با یکدیگر همکاری کنند. با توجه به این که روز به روز دنیا به سمت شیوه های کاری از راه دور حرکت می کند، وقتی که ایستادن همه در کنار وایت بورد فیزیکی غیرممکن است، این ابزار واقعا ارزشمند می شود.

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

خب، حالا سراغ مراحل کار می رویم.

ایده پردازی

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

تنها کاری که شما باید در این مرحله انجام بدهید؛ خالی کردن ذهن تان از هر ایده ای که در مورد کسب و کارتان دارید و روی کاغذ آوردن آن ها است. در این مرحله نیازی به سازماندهی یا دسته بندی نیست، فقط کافی است همه چیز را یادداشت کنید. یادتان باشد که یک رویداد همیشه مربوط به زمان گذشته است. SubmitOrder یک رویداد نیست؛ اما OrderSubmitted یک رویداد است.

جدول زمانی

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

هر کسی که تا به حال غذای آنلاین سفارش داده باشد، باید با این سری از رویداد ها آشنا باشد.

1-سفارش ارسال شد (Ordersubmitted)

2- موجودی بررسی شد (StockChecked)

3- پرداخت پردازش شد (PaymentProcessed)

4- سفارش پخت (OrderCooked)

5- سفارش اعزام (OrderDispatched)

6- سفارش تحویل شد (OrderDelivered)

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

حتما دانلود کنید: آموزش همه نکات کاربردی طراحی رابط کاربری

خط مشی یا چارچوب

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

به نظر من تقسیم کردن این ها به صورت فلوچارت خطوط شنا یا Swimlane برای افراد یا سیستم‌ های مختلفی که روی سیستم تأثیر می‌ گذارند، مفید است. همچنین شامل هر سیستم خارجی (پردازنده ‌های پرداخت، سیستم ‌های CRM) می ‌شود که وضعیت را البته بدون دخالت مستقیم انسان تغییر می ‌دهند.

فعل و انفعالات

فاز چهار جایی است که همه چیز جالب تر می شود. اینجا جایی است که من UI یا UX را از طریق دستورات به رویداد ها متصل می کنم.

در نظر گرفتن اولین گردش کار برای یک نمونه خاص:

1-یک مشتری با یک صفحه UX تعامل دارد که به آن ها امکان سفارش می دهد.

2- UX یک فرمان SubmitNewOrder را ارسال می کند.

3- یک رویداد OrderSubmitted به وجود می آید.

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

در این مرحله صحبت در مورد محتویات دستور می تواند کمک کننده باشد. فکر کردن در مورد چیزی که در قالب دستور SubmitStockCheckResults قرار می گیرد؛ می تواند به شناسایی هر گونه داده گمشده در مراحل اولیه کمک کند.

اطلاع رسانی به کاربران

در فاز پنج به بررسی اطلاعاتی که کاربران برای تصمیم گیری به آن نیاز دارند، می پردازیم.

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

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

باز هم، مهم است که در این جا درگیر جزئیات نشوید. فرقی نمی کند که از صف، جریان رویداد یا پایگاه داده رابطه ای استفاده می کنید.

آنچه مهم می باشد؛ این است که داده ها باید در قالبی خودمانی و دوستانه در معرض دید قرار بگیرند تا بتوان از آن ها برای تصمیم گیری آگاهانه در مورد سیستم استفاده کرد .

این مدل های خواندنی به عنوان لیست کار هایی که باید انجام بدهید در نظر گرفته می شود و من واقعا این ایده را دوست دارم. فهرست کار ها مفهومی است که تقریبا همه می توانند آن را درک کنند.

حتما بخوانید: آموزش صفر تا صد طراحی سایت

سیستم می‌ گوید در این جا برخی از داده ‌ها هستند که باید یک عمل روی آن ها انجام شود.

من متوجه شدم که در این مرحله است که هر عیب و نقصی خودش را نشان می دهد. به طور مثال در تصویر بالا، دستور SubmitPaymentResult اتفاق می ‌افتد که منجر به یک رویداد PaymentProcessed می ‌شود. این رویداد یک قسمت PaymentSuccess دارد که به نظر می ‌رسد باید در گردش کار مشروط و بسته به شرایط باشد.

هنگامی که رویداد PaymentProcessed رخ می دهد، سفارش در لیست کار های OrdersAwaitingCook قرار می گیرد. اما اگر پرداخت انجام نشد ، چه؟

و اینجاست که اهمیت و ارزش مدل‌ سازی رویدادی مشخص می‌ شود. شما یک اتاق پر از افراد فنی و غیر فنی دارید که می توانند به یک زبان صحبت کنند و رفتار سیستم را توجیه کنند. در ادامه بخشی از مکالمه بین افراد درگیر یک پروژه مدل سازی را می بینید که در مورد مشکلاتی که ممکن است پیش بیاید و چاره کار بحث می کنند:

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

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

گروه بندی خدمات

حال تقریبا کار تمام است!

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

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

همه زبانهای برنامه نویسی را در اینجا آموزش داده ایم، کاملا رایگان!

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

بله، این پروسه خیلی شبیه به میکرو سرویس ها است.

سناریوها

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

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

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

تیم های توسعه ممکن است داستان هایی در Jira یا کارت هایی روی بورد های Trello داشته باشند. این تا حد زیادی بی ربط است. این مفهوم زبان مشترک کل سیستم است و می توان از آن برای منطقی کردن سناریو های مختلف استفاده کرد.

نکته

اطلاعات اضافی هست که من می ‌خواستم در پایان به آن ‌ها بپردازم تا به سؤالاتی که در اولین برخورد با این مدل داشتم، پاسخ بدهم.

اجرا بی ربط است

اگر یک چیز وجود داشته باشد که من بخواهم حذف کنم، چیزی است که اجرایش بی ربط است. این مورد چه تامین کنندگان پایگاه داده و پیاده سازی های فهرست و چه زبان برنامه نویسی باشد؛ باید حذف شود.

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

حتما بخوانید: یادگیری چند زبان برنامه نویسی (و فواید آن)

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

قرارداد سطح دسترسی می تواند مهم باشد

با این که پیاده سازی اش نامربوط است، اما ذکر هر گونه عملیات حساس به زمان در نمودار می تواند مفید باشد.

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

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

وایرفریمینگ

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

طراحی وایرفریم: آموزش صفر تا صد و 10 باید و نباید مهم

در یک جلسه کاری معمولی، این وایرفریم ‌ها به گونه ‌ای طراحی می ‌شوند که واقعا می‌ خواهید UI ظاهر شود. اگر قرار بود UI سه ورودی، یک منوی کشویی و یک دکمه داشته باشد، ادامه بدهید و یک وایرفریم در Miro ایجاد کنید که شبیه چنین چیزی است.