مدل سازی رویداد چیست؟ مراحل را مرحله به مرحله انجام دهید

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

برنامه خود را آنطور که می خواهید طراحی کنید، نه آنطور که در حال حاضر کار می کند!

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

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

مقدمه ای بر مدل سازی رویداد

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

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

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

قدم به قدم

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

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

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

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

خوب، اکنون به مراحل کاری می رویم.

یک ایده

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

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

جدول زمانی

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

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

1-سفارش ارسال شد

2- بورس اوراق بهادار

3- پرداخت انجام شده است

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

5- سفارش ارسال شد

6- سفارش تحویل داده شده است

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

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

یک سیاست یا چارچوب

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

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

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

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

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

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

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

3- یک رویداد OrderSubmitted ایجاد می شود.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الان کار تقریبا تمام شده!

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

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

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

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

بله، این فرآیند بسیار شبیه به میکروسرویس ها است.

اسکریپت

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

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

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

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

نکته

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

عملکرد بی ربط است

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

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

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

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

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

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

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

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

قاب ها

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

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

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