در قسمت اول از این سری با کلیات Event Storming و اینکه چرا باید با این روش آشنا باشیم و از آن استفاده کنیم آشنا شدیم. سپس در دومین قسمت به سراغ بررسی شرایط برگزاری جلسه رفتیم و دیدیم قبل، هنگام و بعد از برگزاری جلسه چه کارهایی باید انجام دهیم. در سومین قسمت از این مجموعه به بررسی شرایط یک جلسه واقعی پرداختیم و سعی کردیم در قالب یک مثال یک جلسه واقعی را مدل‌سازی کنیم. حالا در آخرین قسمت از این مجموعه به سراغ استفاده از Event Storming برای طراحی مدل می‌رویم.
1. مقدمه:
تا به اینجای کار با مفهوم Eventها آشنا شدیم. در بخش‌های قبلی بعد از اینکه Eventها را شناسایی کردیم با نقاط بحرانی و نحوه برخورد با آن‌ها برای جلوگیری از آشفتگی جلسه و از دست رفتن زمان آشنا شدیم. سپس دیدیم که با توجه به شرایط نیاز داریم هنگام کار کردن با سیستم‌های خارجی، از ریسک‌های کار با آن‌ها مطلع باشیم و برای همین یک عنصر بصری و رنگ اختصاصی نیز به سیستم‌های خارجی اختصاص دادیم. بعد از اینکه در جلسات قبل موفق شدیم یک تصویر کلی از سیستم به دست بیاوریم در این قسمت قصد داریم با دانش قبلی، همراه با BEهای مسلط‌تر جزئیات بیشتری از دامنه را شناسایی کنیم. در پایان این قسمت مفاهیم و رنگ‌های بیشتری به سیستم اضافه خواهد شد و میتوانیم کم کم کار توسعه را شروع کنیم.
2. کمی عمیق‌تر:
بیایید قبل از ادامه کار با هم نگاهی به دستاوردمان تا اینجای کار داشته باشیم. به سراغ محصولی می‌رویم که پس از جلسه قبلی تولید کردیم تا ببینیم حاصل کار ما از این جلسه Event Storming چه بوده است؟ برخی از سوالاتی را که در جلسه قبل به دنبال پاسخ به آن‌ها بودیم در ادامه مشاهده می‌کنید:
تا اینجای کار، حاصل زحمت‌ها و صحبت‌های ما همراه تیم، حول محور سوالات بالا باعث شده تابلویی داشته باشیم پر از Stickyهای نارنجی که Eventهای دامنه را تعیین می‌کنند. البته هنگام برگزاری جلسه، سوالاتی نیز ایجاد شد که برای آن‌ها جوابی نداشتیم و نمی‌توانستیم فوری پاسخ دهیم، یعنی در اصل شرکت‌کنندگان در جلسه برای این سوالات نقص دانش داشتند و برای اینکه خدای ناکرده این مسائل فراموش نشوند با Sticky سرخابی جوری که توی ذوق بزند این نقص دانش را روی صفحه چسباندیم.
پس از پایان این جلسه همه اعضا دید خوبی از دامنه مورد نظر پیدا کرده‌اند و احتمالا به راحتی می‌توانند راجع به بخش‌های مختلف به تبادل نظر بپردازند. اما به جرات می‌توان گفت که هیچ یک از اعضای تیم جرات شروع کردن کد‌نویسی را نخواهند داشت. برای شروع توسعه نرم‌افزار نیاز به دانشی عمیق‌تر از عملکرد سیستم وجود دارد و باید دقیقا بدانیم چه کارهایی توسط چه کسانی در سیستم انجام می‌شوند. برای همین یک جلسه Event Storming دیگر تشکیل می‌دهیم تا بتوانیم جزئیات بیشتری از دامنه را کشف کنیم.
3. آمادگی برای جلسه Event Storming:
نیازمندی‌های ما نسبت به جلسه قبل تغییری نمی‌کند. کماکان به مقدار زیادی کاغذ، Sticky و ماژیک نیاز داریم. در این جلسه قرار است جزئیات دقیق‌تری را کشف کنیم. پس قبل از هر کاری نیاز داریم با توجه به تصوری کلی که از کسب و کار داریم، یک قسمت را برای اکتشافات جدید و دقیق‌تر خود انتخاب کنیم. به جرات می‌توانم بگویم انجام صحیح این کار و انتخاب بخش درست یکی از اساسی‌ترین و سخت‌ترین کار‌های توسعه نرم افزار است. در مرحله بعد به سراغ دعوت از شرکت‌کنندگان می‌رویم. کماکان تیم توسعه در این جلسه حضور خواهند داشت، اما از حوزه کسب و کار فقط افرادی که دقیقا در این بخش مشغول به کار هستند را باید دعوت کنیم. قاعدتا این جلسات شرکت کنندگان کمتری نسبت به جلسات شناخت عمومی دارند. با توجه به محدود شدن حوزه کسب و کاری که در این جلسه می‌خواهیم صحبت کنیم، و کمتر شدن تعداد شرکت کنندگان، این مجال را خواهیم داشت تا مسائل را با جزیئات بیشتری بررسی کنیم. در این جلسات دیگر خبری از چندین گروه و صحبت در مورد چندین موضوع مختلف نیست. بلکه عموما بحث‌های گروهی حول یک محور شکل خواهد گرفت و افراد مختلف، تجارب، نظرات و دانش خود را در آن زمینه خاص با سایرین به اشتراک خواهند گذاشت.
4. معرفی نماد‌ها و رنگ‌های بیشتر به مدل:
با توجه به اینکه جلسات Event Storming و مدل آن وابسته به زبان و تکنولوژی خاصی نیستند، در این جلسات نمی‌توانیم راجع به مسائلی مثل کلاس، متد و خواص و ... که مربوط به نوع خاصی از زبان یا تکنولوژی هستند صحبت کنیم و مجبوریم در مورد مفاهیم عمومی‌تر از این‌ها صحبت کنیم. اگر کمی به نرم‌افزارها دقت کنیم در میابیم که عموما نرم افزارها شامل تعدادی دستور(Command) هستند که اهداف کاربر را از اجرا نمایان می‌کنند. سپس با توجه به هر دستور، مدل برنامه اعمالی را انجام داده و وضعیت داخلی برنامه تغییر می‌یابد که در نتیجه یک Event رخ می‌دهد که در دل خود هدف کاربر و تغییر وضعیت را خواهد داشت. اما کاربر برای اینکه یک Command را اجرا کند باید داده‌هایی را دریافت کند تا بر مبنای آن داده‌ها بتواند تصمیم‌گیری کند دستوراتی را صادر کند. برای تامین این داده‌ها برای کاربر پرس و جو‌هایی (Query) اجرا می‌شود. اگر به مطالبی که گفته شد دقت کنید میبینید به کمک مفاهیمی مثل کاربر، دستور و پرس و جو میتوانیم مدلی ایجاد کنیم که به هیچ زبان و تکنولوژی وابسته نیست.
4.1. دستورات (Commandها)
همانطور که مشاهده می‌کنید Commandها و Eventها به هیچ زبان و تکنولوژی خاصی اشاره نمی‌کنند. هر دو این مفاهیم عملکر‌های سیستم را از جهات مختلفی آشکار می‌کنند و در این راه از UL بهره می‌برند و کاملا هدف کاربر را آشکار می‌سازند.
بنابراین ما Commandها را به عنوان عضو جدیدی از مدل معرفی می‌کنیم. Commandها هدف کاربر از استفاده از سیستم را مشخصی می‌کنند و با توجه به ماهیت دستوری که دارند موجب تغییر وضعیت داخلی سیستم شده و نهایتا موجب رخدادن یک Event می‌شوند. برای معرفی یک Command به سیستم از Stickyهای آبی استفاده می‌کنیم.
همانطور که در تصویر مشاهده می‌کنید برای ارتباط دادن یک Command به یک Event از هیچ علامتی استفاده نمی‌شود، بلکه این ترتیب قرارگیری منطقی علائم در تابلو است که ارتباط اجزا به یکدیگر را تعیین می‌کند. ابتدا به سیستم دستور داده می‌شود که کاری را انجام دهد و سپس در صورت امکان سیستم عملیات را انجام داده و وضعیت داخلی را تغییر می‌دهد و یک Event رخ می‌دهد.
4.2. دریافت داده‌ها برای نمایش (Read Model):
علامت بعدی که به مدل ما اضافه می‌شود Read Model نام دارد. داده‌هایی که در اختیار کاربر قرار می‌گیرد تا به کمک آن بتواند تصمیم بگیرد چه عملیاتی را انجام دهد اصطلاحا Read Model می‌نامیم. هر صفحه‌ای که همراه داده در نرم افزار در اختیار کاربر قرارمیگیرد را Read Model می‌نامیم. این صفحات می‌توانند شامل فرم، داشبور یا گزارش باشند. هر اطلاعاتی که به کاربر داده می‌شود و کاربر به کمک آن می‌تواند برای انجام یک Command تصمیم گیری کند را به کمک Read Model نمایش می‌دهیم و برای این کار از رنگ سبز روشن استفاده می‌کنیم. اساسا با توجه به شرایط بهتر است از Stickyهای بزرگتر از معمول برای نمایش Read Model استفاده کنیم.
4.3. کاربران (Users)
به طور معمول سیستم‌های نرم‌افزاری توسط افرادی که در سیستم به عنوان User شناخته می‌شوند مورد استفاده قرار می‌گیرند. از آنجایی که همه کاربران اجازه استفاده از همه قسمت‌های سیستم را ندارند، به کاربران نقش‌هایی تخصیص داده می‌شود که در سیستم عملکردشان را تعیین می‌کند. به طول کلی برای مدل سازی دقیق سیستم نیاز داریم بدانیم کدام کاربر دستور را اجرا می‌کند. به همین دلیل عضو جدیدی برای نمایش User به سیستم اضافه می‌کنیم.
به همین منظور ما User را با یک Sticky زرد رنگ به مدل اضافه می‌کنیم. اساسا برای نمایش کاربران از Stickyهای کوچکتری نسبت به حالت معمول استفاده می‌کنیم. دقت کنید یک کاربر در سیستم‌های نرم افزاری می‌تواند نقش‌های متفاوتی داشته باشد و منظور ما در این قسمت از کاربر دقیقا یک نقش خاص است مثل خبرنگار، سردبیر، بانکدار و ...
ممکن است دو نقش متفاوت یک Read Model را ببینند اما با توجه به سیاست‌های کاری Commandهای متفاوتی را بتوانند به اجرا در آورند.
4.4. قواعد و سیاست‌های کاری (Policyها):
در انتها، به سراغ قواعد و سیاست‌های کاری می‌رویم این عنصر را که با عنوان Policy می‌شناسیم به مدل خود اضافه می‌کنیم. همانطور که قبلا توضیح داده شد کاربران در سیستم کارهایی را انجام می‌دهند و نتیجه پردازش دستورات کاربر تغییر وضعیت داخلی سیستم و رخدادن یک Event است. با توجه به رخدادی که در سیستم منشر می‌شود، بخش‌های دیگری از سیستم نیز که Command را مستقیما دریافت نمی‌کردند از این Command و Event با خبر می‌شوند و ممکن است شروع به اجرای دستوراتی کنند. هر چه تعداد این دستورات پیرو بیشتر شود، سیستم پیچیده‌تر و کندتر خواهد شد. کاربر یک کار ساده انجام می‌دهد و پیرو آن ده‌ها کار دیگر باید انجام شود تا کاربر کنترل سیستم را باز پس گیرد و در نتیجه کار به سرانجام برسد. بهتر است حتی الامکان این دسته دستورات کمتر شوند و هرچه سریع‌تر کار انجام شده و کنترل به کاربر بازگردد. اینجا دقیقا جایی است که Policyها وارد بازی می‌شوند. Policyها می‌توانند برای دریافت رخداد‌های مختلف در سیستم ثبت‌نام کنند و با وقوع آن عملیاتی را به صورت آسنکرون در سیستم اجرا کنند. عملا Policyها می‌توانند به جای Userها Commandی را به سیستم بدهند و موجب انجام کاری در سیستم شوند. برای معرفی Policyها به سیستم از رنگ بنفش استفاده می‌کنیم.
با کمی دقت در تصویر بالا به راحتی میتوانیم روال زیر را از عملکرد سیستم به دست آوریم. "هنگامی که مالک یک آگهی آن را در وضعیت فروش رفته قرار می‌دهد به صورت اتوماتیک سیستم آگهی را غیرفعال می‌کند."
4.5. خلاصه:
به صورت خلاصه عملکرد سیستم را می‌توان به این شکل خلاصه کرد که ابتدا کاربر یک Read Model را از سیستم دریافت می‌کند و با مشاهده آن و دانشی که از کسب و کار دارد و از دنیای واقعی به دست می‌آورد یک Command را در سیستم به اجرا در می‌آورد. در نتیجه اجرای یک Command داده‌های سیستم ممکن است تغییر کند و وضعیت داخلی سیستم تغییر کند و موجب وقوع یک Event در سیستم می‌شود. با وقوع یک Event ممکن است Policyهایی در سیستم فعال شوند و خود Policyها نیز Commandهایی را در سیستم به اجرا در آورند. شایان ذکر است به جز کاربران سیستم‌های خارجی نیز می‌توانند موجب ایجاد یک Event در سیستم شوند.
5. جمع بندی:
در آخرین مطلب از این سری سعی کردیم تمامی علائم و عملکردهای موجود در یک مدل که حاصل جلسات Event Storming است را بررسی کنیم. حالا نوبت استفاده از این روش رسیده با توجه به این شرایط نیاز است کمی در این راه تجربه عملی به دست آوریم.
پ.ن. خوشحال می‌شوم که مدل موجود در جلسه قبل را با توجه به شناختی که تا اینجای کار بدست آورده اید تغییر داده و تجربیات خود را با من به اشتراک بگذارید.
