آموزش Domain Driven Design - طوفان رویداد (بخش اول)

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

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

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

چندین مشکل اساسی وجود دارد که نیاز به رفع آنها داریم:

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

در سال 2003، آلبرتو برندولینی، روشی را ابداع کرد و آن را طوفان رخداد (Event Storming) نامید. روشی که تلاش دارد مشکلاتی که در بالا مطرح شد را برطرف کند. ما در این فصل در مورد این روش خواهیم آموخت.

مدلسازی زبان

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

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

بیایید نگاهی به یک مثال ساده از کسی که قبض اش را توسط اینترنت بانک پرداخت می کند، کنیم:

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

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

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

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

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

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

اگر به مثال پرداخت قبض برگردیم، می توانیم تلاش کنیم تا رخدادهایی که آنجا رخ می دهد را بیابیم:

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

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

تصویر سازی (Visualization)

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

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

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

یک مساله ای اینجا پیش می آید، که می تواند برای کسانی که بهترین تلاششان را برای ساخت یک مدل رخداد انجام می دهند زیان آور باشد. تصور کنید چنین ورکشاپی در یک اتاق جلسه برگزار می شود. معمولا افراد بین یک میز نشسته و صحبت می کنند. همانطور که قبلا گفتیم، این روشی نیست که طوفان رویداد از آن استفاده می کند. ما از افراد انتظار داریم که در اتاق حرکت داشته باشند و فعالانه در بحث مشارکت کنند. این مشارکت ممکن است به صورت همزمان در نقاط مختلفی از اتاق رخ دهد. پس ما نیاز به فضای بیشتری داریم. اما این همه فضایی نیست که به آن نیاز داریم. داشتن نگاه درست به مدل فرایندی ساده گذشته. اگر چه توافق داریم که مدل ما فقط مسیر شادی (happy path) را در نظر گرفته و استثنائات (edge cases and exceptions) را نادیده گرفته، اما می دانیم که دنیای واقعی این گونه برخورد نمی کند. نمودار ساده ما هم اکنون نیز فضای افقی ای را گرفته است. حالا فرض کنید سناریوهای دنیای واقعی اینگونه مدل سازی شوند. در واقع یک وایت برد 2 3 متری برای شما نمی تواند به درستی خدمات دهی کند!

تصور کنید مدل شما چیزی شبیه به این است:

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

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

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

پایان بخش اول