خانه مهندسی نرم افزار قسمت دوم EventStorming: آماده سازی شرایط جلسه مهندسی نرم افزار DDD نوشته شده توسط: علیرضا ارومند تاریخ انتشار: ۱۷ فروردین ۱۳۹۹ آخرین بروزرسانی: ۲۱ مهر ۱۴۰۱ زمان مطالعه: 36 دقیقه ۴ (۵) مقدمه در قسمت قبل [آشنایی با Eventstorming] از این سری با کلیات Event Storming و اینکه چرا باید با این روش آشنا باشیم و از آن استفاده کنیم آشنا شدیم و در این قسمت قصد داریم جزئیات بیشتر و کاربردیتری را در باره Event Storming بررسی کنیم.در هر جلسه Event Storming افراد مختلفی در جلسه شرکت میکنند. یکی از شرکت کنندگان در این جلسه که وظیفه برگزاری جلسه و تسهیل امور را برعهده دارد اصطلاحات facilitator نامیده میشود. با یک تعریف ساده میگوییم facilitator مدیر جلسه محسوب میشود، البته صرفا جهت سادگی درک نقش facilitator این تعریف را انجام میدهیم. در این قسمت قصد داریم جزئیات بیشتری در مورد Event Storming را بیان کنیم و در ادامه مطالبی که به عنوان یک facilitator باید بدانیم را بیان کنیم. پیش از اینکه به ادامه بحث بپردازیم ذکر این نکته خالی از لطف نیست که برای استفاده از این روش نیازه به استفاده از DDD نیست. هرچند این جلسات همزمان با DDD معرفی میشوند، اما به عنوان یک ماهیت کاملا مستقل باید به آن نگاه کنیم که به ما امکان ارتباط بهتر در تیم توسعه و کسب و کار، و شناخت بهتر صورت مسئله را میدهد. شرکت کنندگان در جلسه مسلما یکی از نکاتی که درباره هر جلسه باید وجود داشته باشد، دعوت از شرکت کنندگان است. اما چه افرادی را باید به جلسات Event Storming دعوت کنیم؟ طبق تعریفی که در گذشته انجام دادیم ما در این جلسات نیاز به افرادی داریم که در مورد فضای کسب و کار سوال داشته باشند و در کنار آنها باید شرکت کنندگانی داشته باشیم که بتواند به سوالات پاسخ دهند.سوالات معمولا نزد تیم توسعه است، پس افراد تیم توسعه شامل تحلیلگران، معماران نرمافزار و توسعه دهندهها باید در این جلسات حضور داشته باشند. متاسفانه توسعه دهندهها معمولا علاقهای به شرکت در جلساتی با موضوع غیر فنی ندارند و ترجیح میدهند این کار توسط تحلیلگران انجام شود، اما با توجه به نقش حیاتی آنها در توسعه نرمافزار و نیاز به درک کامل آنها از صورت مسئله باید در جلسه حضور داشته باشند. حالا که تکلیف سوال پرسیدن مشخص شد، نیاز به شرکت کنندگانی داریم که بتوانند به سوالات پاسخ دهند. افراد مختلفی در سازمان ممکن است جواب سوالها را بدانند مثل Stack Holderها. اما با توجه به اینکه نیاز به دانش دقیقی داریم باید به سراغ افرادی برویم که با جزئیات کار درگیر هستند پس به سراغ Business Expertها میرویم و از آنها برای شرکت در جلسه دعوت میکنیم. سعی کنید چندین BE را به جلسه دعوت کنید. با توجه به تخصصی بودن کار هر فردی دانش قسمتی از کار را دارد و ممکن است دانش وی در مورد سایر قسمتها ناقص یا اشتباه باشد. پس بهتر است چندین شرکت کننده داشته باشید. البته به این نکته دقت کنید که با توجه به مشغله کاری BEها هماهنگی و جمع کردن چند نفر از آنها در یک جلسه کاری دشوار است. در سازمانها دو دسته BE وجود دارد. آنهایی که میدانند کارها چگونه باید انجام شود (مدیران) و آنهایی که واقعا میدانند کار چگونه انجام میشود (کارشناسان) پیشنهاد میکنم از هر دو دسته مدعو داشته باشید، اما اگر مجبور به انتخاب بودید کارشناسان انتخاب بهتری برای دعوت به این جلسات هستند.از آنجایی که قرار است جلسهای کاملا پویا داشته باشیم، بهتر است قبل از جلسه به هر دو گروه سوال کنندگان و پاسخ دهندگان آمادگی لازم جهت جلسه را بدهید تا بتوانند ذهن خود را ساختار دهی کرده و آماده شرکت در جلسه باشند و از زمان جلسه بیشترین استفاده بشود. آمادگی برای یک جلسه خوب شاید برای شما هم پیش آمده باشد که برای یک جلسه دعوت میشوید و هنگامی که جلسه شروع میشود با یک فاجعه تمام عیار مواجه میشوید. هیچ چیز برای برقراری جلسه آماده نیست. نیاز به نمایش موضوعی روی پرده دارید اما ویدئو پروژکتور از کار افتاده است. یا کابل آن قدیمی است و با ورودی لپ تاپ شما هماهنگی ندارد. کلی زمان سپری میشود تا زیرساخت لازم فراهم شود و در این مدت هیچ کار مفیدی انجام نمیشود و وقت همه شرکت کنندگان هدر میرود. بعد از آماده شدن زیرساخت هم حوصله و زمان کافی برای برگزاری یک جلسه مناسب وجود ندارد. این دقیقا شرایطی است که ما باید از آن جلوگیری کنیم و در این قسمت میخواهیم پیشنهاداتی جهت جلوگیری از وقوع این شرایط ارائه کنیم. مواد لازم از قدیم به یاد داریم که هیچ چیز به اندازه رفیق ناباب و ذغال خوب توی زندگی تاثیر گذار نیست. حالا که مدعوین را دعوت کرده ایم و رفیق ناباب آماده شده، باید ذغال خوب هم فراهم کنیم.حالا که سوال کنندگان و پاسخ دهندگان را دور هم جمع میکنیم، میتوانیم خیلی سریع مدلسازی را شروع کنیم و قبل از اینکه مدلسازی شروع شود باید فضای مدلسازی را آماده کنیم. به یاد دارید که مسئله ما بزرگتر از وایتبردهایی است که معمولا در اتاق جلسات نصب میشود. خوب حالا که وایتبردها کاربرد ندارند گزینه بعدی ما استفاده از دیوارهای اتاق جلسات است، اما معمولا Stickyها روی این دیوارها به خوبی متصل نمیمانند مگر اینکه دیوارها شیشهای باشند. البته بهتر است به یاد داشته باشیم که مدل ما قرار نیست در فضای عمومی جلسات باقی بماند و باید قابلیت جابجایی هم داشته باشد و با توجه به این نکات دیوارها انتخاب مناسبی نیستند. بهترین گزینه در این شرایط استفاده از رولهای کاغذی است. مواردی مثل رولهای دستگاههای پلاتر که طول نامحدودی از کاغذ با عرض مناسب را در اختیار ما قرار میدهند. این کاغذها همه ویژگیهای دلخواه ما را دارند. هر زمانی نیاز داشته باشیم طول آنها اضافه میشود. قابل جمع شدن و جابجایی است و نصب Stickyها روی آنها به خوبی انجام میشود.بعد از تهیه رولکاغذ باید به فکر نصب آن روی دیوار باشیم و ابزاری جهت نصب کاغذ روی دیوار داشته باشیم. قبل از هر چیز بازدیدی از اتاق جلسه خواهیم داشت تا با توجه به نوع دیوار ابزار مناسبی انتخاب کنیم. مسلما اگر دیوار گچی باشد نیاز به ابزاری مثل پونز یا منگنه داریم و اگر دیوار شیشه ای باشد باید به سراغ چسب مناسب برویم. هنگام بازدید از اتاق دقت کنید مانعی برای نصب کاغذ مثل تابلو یا پنجره یا … در دیوار اتاق وجود نداشته باشد. بزار بعدی که نیاز داریم آماده کنیم، تعداد زیادی Sticky است. با توجه به اینکه نمیدانیم با چه مسئلهای مواجه میشویم باید تعداد زیادی Sticky تهیه کنیم که هنگام تحلیل به مشکل کمبود کاغذ برخورد نکنیم. دقت کنید که ارزش دانش کسب و کار بسیار زیاد است و هزینه خرید Stickyها در برابر این دانش هیچ است. پس باید به اندازهای Sticky همراه داشته باشیم که به خاطر کمبود Sticky دانش ارزشمند را از دست ندهیم. هنگامی که Stickyها را تهیه میکنید دقت کنید که این Stickyها باید در اندازهها و رنگهای متفاوت تهیه شود تا بنا به مورد استفاده بتوانیم از رنگ و سایز دلخواه استفاده کنیم. آخرین ابزاری که برای کار نیاز داریم وسیلهای برای نوشتن است. این گزینه معمولا فراموش میشود و تعداد زیادی از افراد مهم را دور هم جمع میکنیم و فقط یک خودکار یا ماژیک برای نوشتن داریم و با توجه به این محدودیت بهرهوری جلسه کاهش مییابد. بهتر است به تعداد شرکت کنندگان در جلسه وسیله نوشتن داشته باشیم و یکی دوتا هم اضافه برای مواقع اظطرار در نظر بگیریم. از بین وسایل مختلف نوشتن به نظر ماژیک های سایز متوسط هم قابلیت نوشتن بهتری داشته باشند و هم بعد از نوشتن خوانایی نوشته بهتر از خودکار باشد. اتاق جلسه بر خلاف جلسات معمول که شرکت کنندگان معمولا دور میزهایی بزرگ مینشینند و صحبت میکنند، در این جلسات باید شرکت کنندگان بتوانند به سادگی در محیط حرکت کنند و به بررسی مدل توسعه داده شده بپردازند و بتوانند با هم در باره مدل صحبت کنند. پس باید فضای اتاق برای این جابجاییها و راه رفتنها مناسب باشد. اگر در اتاق میز و صندلی وجود دارد بهتر است آنها را جمع کنید و اگر فضایی بیرون از اتاق برای قراردادن آنها ندارید همه را در گوشهای که مزاحم جلسه نباشد جمع کنید. صرفا داشتن یک میز کوچک برای قراردادن ماژیکها یا وسایل جزئی دم دستی مثل stickyها کفایت میکند. با توجه به زمان طولانی جلسه و فعالیت زیاد شرکت کنندگان باید راهی برای سرحال آوردن آنها نیز داشته باشید و داشتن خوراکیهای جزئی و قهوه و … میتواند به برگزاری بهتر جلسه کمک کند. برگزاری جلسه حالا که همه پیششرطها آماده شد، یعنی هم شرکت کنندگان دعوت شدند و هم فضای کاری آماده شد، نوبت به برگزاری جلسه میرسد و در ادامه نکاتی را برای برگزاری هرچه بهتر جلسه با هم بررسی میکنیم. برنامهریزی و زمانبندی جلسه هنگامی که برای جلسه برنامه ریزی میکنید، حداقل ۲ ساعت زمان برای جلسه در نظر بگیرید. احتمالا فکر میکنید ۲ ساعت کم است و شاید اشتباه هم فکر نکنید. اما نکته اصلی این است که سرحال و متمرکز نگه داشتن شرکت کنندگان در جلسه برای زمانی بیش از این شاید سخت باشد. بعضا اگر جلسات زیاد طولانی شود گفتگوها در یک چرخه تکرار میافتد و بهتر است برای طراحی جلساتی طولانیتر از این زمان خوب فکر و برنامه ریزی کنید. معمولا ابتدای جلسات بسیار شادب و جذاب جلو میرود و بعد از گذشت ۱ ساعت انرژی تیم کم میشود. در این شرایط بهتر است مدت زمانی را برای استراحت گروه در نظر بگیرید تا با صرف چای و قهوه انرژی گروه بازسازی شود.نکته قابل توجه در زمان استراحت این است که معمولا گفتگوی بین شرکت کنندگان حول محور جلسه ادامه پیدا میکند اما این بار در محیطی دوستانهتر و با ذهنی آرامتر. بعد از زمان استراحت با توجه به صحبتهایی که شده و آرامشی که بعد از طوفان اولیه ایجاد شده یا وقایع جدیدی در سیستم شناسایی می شود یا به کمک تکنیکهایی که در ادامه بررسی خواهیم کرد، شناخت دقیقتری از شرایط موجود خواهیم داشت. شروع جلسه معمولا شروع جلسه کمی سختتر از ادامه دادن آن است به خصوص اگر قرار باشد با تیمی که تا کنون چنین جلساتی نداشتهاند کار کنیم. پس خیلی سریع قواعد کلی و چگونگی انجام کار را توضیح داده و سپس stickyها و ماژیکها را در اختیار کل گروه قرار میدهیم. در این شرایط اولین قدم به عهده برگزارکننده جلسه است و برای شروع قسمتی را برای نمادها در نظر میگیریم و اولین نماد را در آن قسمت معرفی میکنیم برای این کار روی یک sticky نارنجی مینویسیم domain event و با توضیح اینکه domain event یک رخداد در سیستم است آن را در قسمت نمادها نصب میکنیم. این قسمت چیزی شبیه به راهنمای نقشه است که با یک نگاه سریع به آن، میتوانیم مفهموم و دلیل وجودی نشانههای مختلف را متوجه شویم. سپس در ادامه فضا یک نمودار در محور افقی رسم میکنیم که مربوط به زمان است. حالا نوبت به سختترین قسمت کار میرسد. شروع مستندسازی که نیاز دارد اولین رخداد ثبت شود. به دلایل مختلف این قدم بسیار دشوار است. برای اغلب افراد شروع کار در جمع سخت است، حال اگر این کار، کاری باشد که در آن تجربه قبلی هم ندارند قطعا شرایط سختتر هم میشود. به همین دلیل احتمالا دقایق ابتدایی اولین جلسه با سکوت و تفکر جمع جلو خواهد رفت. در این شرایط نقش facilitator برای آب شدن یخ جلسه بسیار مهم است و این کار سختی نیست. باید این نکته را در نظر بگیریم که با اینکه کل کار ساده است ولی افراد بدون یک مثال عملی نمیتوانند به درستی درک کاملی از شرایط داشته باشند و کار را شروع کنند. پس با توجه به اینکه facilitator پیش از جلسه موضوع و شرایط جلسه را میداند یکی از بهترین راهها برای شروع کار تشخیص و نصب یک یا چند domain event توسط facilitator است. برای انتخاب domain eventها هم کار سختی در پیش نداریم. میتوانیم چند eventساده را انتخاب کرده و در محل صحیح نصب کنیم یا اینکه حتی میتوانیم eventهایی که اشتباه است را بیان کنیم که در این شرایط با مخالفت BEها مواجه میشویم و کار شروع میشود. البته احتمالا اولین عکس العملها به این شکل است که سایر شرکت کنندگان در جلسه به facilitator میگویند که چه اندیشهای در سر دارند و از او میخواهند که اندیشههای آنها را همانطور که توضیح داده پیاده سازی کند و این شروع خوبی است تا ماژیک و کاغذ به دستشان بدهیم و از آنها بخواهیم وارد میدان شوند. احتمالا خیلی سریع همه وارد عمل میشوند و شروع به توضیح و عمل میکنند و اینجا باید به عنوان facilitator نظارهگر باشیم و اشتباهات گروه را بیابیم و نسبت به رفع آن و در مسیر کار قراردادن شرکت کنندگان اقدام کنیم. در ادامه ما فقط راهنما و تسهیل کننده هستیم. با اینکه انتخاب اولین domain eventها برای ما کار سختی نیست و نکته خاصی ندارد اما باید دقت کنیم که این eventها نباید در شروع کار باشند و بهتر است از eventهای میانه راه انتخاب کنیم. نکاتی برای زمان برگزاری جلسه به عنوان facilitator وظیفهما قانون گذاری و کنترل نیست بلکه باید نقش نظارهگر و راهنما را داشته باشیم. هرچقدر قواعد و قوانین دست و پاگیر کمتری برای شرکت کنندگان وضع کنیم خروجی بهتری دریافت خواهیم کرد. بعد از اینکه گروه دست به کار شدند با مشاهده به تیم خواهید دید که تعدای افراد پرسجوگر هستند و تعدادی دیگر پاسخ گو. در این شرایط به عنوان facilitator باید نکاتی را مدنظر قرار دهیم. از آنجایی که شرکت کنندگان در جلسه facilitator را به عنوان مدیر و برگزار کننده جلسه میشناسند و علاقه افراد به وابستگی به مدیر جلسه احتمالا سوالات زیادی از facilitator پرسیده میشوند و با توجه به جایگاه راهنما به جای پاسخ دادن به سوالات باید افراد را به سایر شرکت کنندگان در جلسه که جواب سوالات را دارند ارجاع دهیم.ممکن است افراد حاضر در جلسه دقیقا متوجه هدف و نحوه بیان domain eventها نشوند و به جای بیان domain eventها شروع به بیان خواستهها کنند که در این شرایط هم باید سریعا جلوی اشتباه را بگیریم و آنها را به نوشتن eventها به جای نیازمندیها ترقیب کنیم.با توجه به شرایط جلسه و اینکه اشتباهات کوچک تاثیر چندانی بر عملکرد کلی تیم ندارد، بهتر است تا زمانی که اشتباه فاحشی رخ نداده، به جای اینکه جلوی کارکردن افراد را بگیریم، از اشتباهات جزئی تا پایان جلسه چشمپوشی کنیم تا جلسه از روال نیوفتد. معمولا به کمک این سه نکته که گفته شد میتوانیم جلسات مختلف را مدیریت کرده و به هدف دلخواه برسیم. اما به هرحال باید این نکته را در نظر بگیریم که این جلسات به شدت وابسته به افراد است و روحیات مختلف افراد ممکن است خروجیهای متفاوت و پیشبینی نشدهای را در پی داشته باشد و مدیریت شرایط پیشبینی نشده فقط با تجربه زیاد ممکن میشود.با توجه به پیچیدگیهای مسائل ممکن است افراد با نظرات یکدیگر مخالفت داشته باشند و بحث و گفتگوی زیادی ایجاد شود که ذات چنین جلساتی است و باید بتوانیم این درگیریها را مدیریت کرده و به سمت فهم مسئله هدایت کنیم. ممکن است توسعه دهندهها کمی از نیازمندیهای پروژه مطالعه کرده باشند و با توجه به روحیه توسعهدهنده سعی کنند در گوشهای جلسه را به پایان برسانند که در این شرایط هم با توجه به اینکه این جلسه برای درک بیشتر برنامه نویسها از مسئله تشکیل داده شده باید بتوانیم آنها را به شرکت بیشتر در تعاملات تشویق کنیم.نکته دیگری که باید در این جلسات به آن دقت کنیم علاقه افراد به در نظر گرفتن شرایط بدون دردسر است. معمولا افراد فقط شرایطی را بیان کرده و در نظر میگیرند که همه چیز به خوبی پیش برود اما خطا و مشکل هم بخشی از هر سیستمی است و باید به این فرایندهای مشکل دار توجه ویژهای بکنیم. برای مثال در حالت عادی احتمالا یک روال سفارش به این شکل است که سفارش ثبت شده و سپس پرداخت برای آن انجام میشود و در نهایت حمل شده و به دست سفارش دهنده میرسد. اما اگر پرداخت ناموفق باشد چه اتفاقی میافتد؟ یا اگر پرداخت درست انجام شود و معلوم شود موجودی در انبار وجود ندارد؟ اگر بسته بعد از ارسال در مسیر گم شود چه اتفاقی خواهد افتاد؟ اگر این سوالها را از توسعه دهندهها بپرسیم جوابی برای آن نخواهند داشت و احتمالا تنها جواب آنها ایجاد یک خطا است. اما برای همین شرایط معمولا در کسب و کارها روالهایی وجود دارد و از قبل به آنها فکر شده که باید این فرایندها را نیز یافته و پردازش کنیم. همیشه شرایط به این سادگی نیست که جواب همه سوالات پیش شرکت کنندگان در جلسه باشد. ممکن است شرایط ویژه در سیستمهایی خارج از سازمان اتفاق بیوفتد. یا ممکن است شرکت کنندگان در جلسه جواب درستی برای شرایط ویژه نداشته باشند یا اصلا شرکت کنندگان برای پردازش شرایط ویژه نظرات متفاوتی داشته باشند و بحث و گفتگوی داغی شروع شود. اما این بحث و گفتگوها همیشه نتیجه ندارد و ممکن است بعد از دقایقی متوجه شویم که در تله بحث بی پایان گرفتار شده ایم. در این شرایط برای جلوگیری از اتلاف وقت باید سریعا وارد عمل شویم و بحث را قطع کرده و فقط یک نمایه برای این شرایط بغرنج در مدل ثبت کنیم. بهتر است از رنگها جیغ برای این کار استفاده کنیم. پیشنهاد آقای Brandolini استفاده از رنگ سرخابی برای این کار است. -با یافتن نکات مشکل دارد و علامتگذاری این نقاط مهم روی مدل زمان را بهتر مدیریت میکنیم و جلوی فراموشی توجه به این نکات را هم میگیریم. ممکن است بعد از پایان جلسه با انبوهی از نکات حساس مواجه شویم و دیوار ما پر از رنگ سرخابی باشد که با توجه به پیچیدگی مسائل طبیعی است. بهتر است بعد از جلسه خیلی سریع جلساتی تشکیل داده تا در مورد این برگههای سرخابی تصمیم گیری و وضعیت ادامه کار را معلوم کنیم.هنگامی که جلسه در حال برگذاری است باید به گروههایی که تشکیل میشود دقت کنیم. احتمالا افراد مختلف با هم گروههایی را تشکیل میدهند روی یک بخش از مسئله تمرکز میکنند. شاید این گروهها و تجمعها نشانههایی برای تشخیص Bounded Contextها و Context Map باشد. در نهایت هنگام برگزاری جلسه ممکن است متوجه شرایطی شویم که نیاز داریم با سیستمی خارج از سازمان خودمان تعامل کنیم. این سیستمها را اصطلاحا external system مینامیم و باید این سیستمها را هم به نحوی در مدل خود نمایش دهیم. ممکن است بعضی از domain eventها از سیستم ما خارج شوند و بعضی از domain eventها هم نتیجه فعالیت سیستمهای بیرونی باشند. با این شرایط باید گزینه جدیدی به مدل خود اضافه کنیم. برای این کار نیاز به رنگی جدید داریم. برای این کار از رنگ صورتی کم رنگ به پیشنهاد آقای Brandolini استفاده میکنیم. در صورتی که بعد از مدتی با شرایطی مواجه شدیم که شرکت کنندگان دیگر حرفی برای گفتن نداشتند و ساکت شده بودند، باید راهکاری بیابیم تا مجددا آتش جلسه شعله ورد شود. یکی از بهترین راهها برای این منظور پیشنهاد بررسی مجدد مدل است. بهتر است به شرکت کنندگان بگوییم یک بار روال کار را از انتها به ابتدا بررسی کنند و ببینند تمامی کارها با ترتیب درست در حال انجام است یا خیر. معمولا اگر رخدادی جا افتاده باشد در این بازبینیها پیدا میشود.به عنوان آخرین نکته در حین برگزاری جلسه به یاد داشته باشیم با اینکه زمان جلسه کوتاه است و به سختی میتوان افراد حاضر در جلسه را دور هم جمع کرد، اما برای بهرهوری جلسه لازم است هر ساعت، استراحتی کوتاه به شرکت کنندگان داده شود تا مجددا آماده شرکت در جلسه شوند. کمی بعد از پایان جلسه بعد از تمام شدن زمان و اینکه شرکت کنندگان جلسه را ترک کردند، یک کاغذ بزرگ با تعداد زیادی Sticky داریم که زمان و انرژی زیادی برای ساخت آن صرف شده است و یک دستاورد ارزشمند از جلسه است. اما اگر جلسات ادامه دارد باشند و با نرمافزارهای زیادی سر و کار داشته باشیم احتمالا بعد از مدتی کل سازمان پر از نوارهای کاغذی میشود. با توجه به اینکه دید کلی از کار را میتوانیم از این مدل بیابیم، بهتر است حتی الامکان این مدل را در جایی که همه اعضای تیم میبینند نصب و نگهداری کنیم و اگر امکان این کار را نداریم باید این نوارها را جمع آوری کرده و در جایی نگهداری کنیم تا در زمان نیاز بتوانیم به آنها مراجعه کنیم. عکس گرفتن از این مدل و در اختیار تیم قراردادن این عکس میتواند به بهره برداری بهتر از این جلسه کمک کند. شاید بد نباشد از ابزارهای آنلاین برای پیاده سازی این مستند استفاده کنیم تا در صورت بروز مشکل برای مستند کاغذی، دستاورد جلسه از بین نرود.بعد از اتمام جلسه باید سریع دست به کار شده برای نکات مبهمی که در جلسه یافتهایم راه حل پیدا کنیم. برای این کار لازم است جلساتی تخصصی با حضور همه BEها تشکیل دهیم. در مدت زمانی که فرصت داریم بهتر است BEهایی را بیابیم که در جلسه نبودهاند و با این شرایط بغرنج آشنا هستند. باید هرچه سریع تر ابهامات را از بین ببریم. جمع بندی در این قسمت با جزیئات بیشتری از Event Storming آشنا شدیم. البته از این تکنیک در لایههای مختلف طراحی از ایجاد دید کلی تا طراحی جزئیات Domain Model میتوانیم استفاده کنیم که در قسمتهای بعدی در مورد این کار بررسیهای دقیقتری خواهیم کرد. چه رتبه ای میدهید؟ میانگین ۴ / ۵. از مجموع ۵ اولین نفر باش دانلود مقاله قسمت دوم EventStorming: آماده سازی شرایط جلسه فرمت PDF 9 صفحه حجم 1 مگابایت دانلود مقاله معرفی نویسنده مقالات 24 مقاله توسط این نویسنده محصولات 43 دوره توسط این نویسنده علیرضا ارومند علیرضا ارومند به عنوان Product Manager شرکت داتین (وابسته به فناپ) در حوزه پروژههای بانکی فعال است.او همچنین مدرس و Technical Manager پروژههای نیک آموز می باشد از دیگر تخصص های او میتوان به: تولید فریمورک برنامه نویسی فوق العاده حرفهای با مدیریت بیش از 1 میلیون تراکنش در ثانیه، همکاری با تیم توسعه شرکت ارتباط فردا (بانک آینده)، مشاور فنی شرکت توسعه رفاه پردیس (بانک رفاه)، مدیر فنی خبرگزاری نسیم، سخنران تنها همایش مورد تایید مایکروسافت در خاورمیانه در حوزه ASP.NET Core، مدیر فنی خبرگزاری بین المللی پیامکوتاه نسیم (برنده جشنواره وب ایران)، مدرس دوره های Dot Net ، ASP.NET در نیک آموز، همکاری با تیم توسعه شرکت ارتباط فردا معرفی محصول علیرضا ارومند دوره آموزش معماری میکروسرویس 5.190.000 تومان مقالات مرتبط ۰۷ فروردین مهندسی نرم افزار تفاوت DDD، میکروسرویس (Microservice)، الگوهای طراحی (Design pattern) و معماری تمیز (Clean Architecture) تیم فنی نیک آموز ۰۳ اسفند مهندسی نرم افزار آشنایی با تفاوت Domain Events و Integration Events تیم فنی نیک آموز ۲۶ بهمن مهندسی نرم افزار ۵ راز ساخت سیستم قدرتمند با پیاده سازی معماری میکروسرویس : چالش ها و راه حل ها تیم فنی نیک آموز ۰۵ دی مهندسی نرم افزار راهنمای مسیر شغلی معمار ارشد نرم افزار تیم فنی نیک آموز دیدگاه کاربران لغو پاسخ دیدگاه نام و نام خانوادگی ایمیل ذخیره نام، ایمیل و وبسایت من در مرورگر برای زمانی که دوباره دیدگاهی مینویسم. موبایل برای اطلاع از پاسخ لطفاً مرا با خبر کن ثبت دیدگاه Δ