فصل ۱۲ — EventStorming

در این فصل از بحث دربارهٔ الگوها و تکنیک‌های طراحی نرم‌افزار فاصله می‌گیریم و به‌جای آن بر یک فرایند مدل‌سازی کم‌فناوری به نام EventStorming تمرکز می‌کنیم. این فرایند جنبه‌های اصلی طراحی دامنه‌محور را که در فصل‌های پیشین بررسی کردیم گرد هم می‌آورد.

در این فصل فرایند EventStorming، چگونگی تسهیل یک کارگاه EventStorming و شیوهٔ استفاده از آن برای اشتراک مؤثر دانش دامنه و ساخت یک زبان فراگیر (Ubiquitous Language) را خواهید آموخت.

EventStorming چیست؟

EventStorming فعالیتی کم‌فناوری است که در آن گروهی از افراد با طوفان فکری، یک فرایند کسب‌وکار را به‌سرعت مدل می‌کنند. از یک منظر، EventStorming ابزاری تاکتیکی برای اشتراک دانش دامنهٔ کسب‌وکار است.

هر جلسهٔ EventStorming یک Scope دارد: فرایند کسب‌وکاری که گروه علاقه‌مند به بررسی آن است. شرکت‌کنندگان این فرایند را به شکل مجموعه‌ای از Domain Eventها روی یک خط زمانی بررسی می‌کنند و هر Event با یک Sticky Note نمایش داده می‌شود. مدل مرحله‌به‌مرحله با مفاهیم بیشتری—Actorها، Commandها، سیستم‌های خارجی و موارد دیگر—غنی می‌شود تا در نهایت همهٔ عناصر آن داستان نحوهٔ کار فرایند کسب‌وکار را بازگو کنند.

چه کسانی باید در EventStorming شرکت کنند؟

در حالت ایده‌آل، گروهی متنوع از افراد باید در کارگاه شرکت کنند. در واقع هر کسی که به دامنهٔ کسب‌وکار مورد بحث ارتباط دارد می‌تواند مشارکت کند: مهندسان، خبرگان دامنه، Product Ownerها، Test Engineerها، طراحان UI/UX، کارکنان پشتیبانی و دیگر ذی‌نفعان. هرچه افراد بیشتری با پیشینه‌های متفاوت درگیر شوند، دانش بیشتری کشف خواهد شد.

با این حال، مراقب باشید گروه بیش از حد بزرگ نشود. هر شرکت‌کننده باید بتواند واقعاً به فرایند کمک کند و این موضوع برای گروه‌های بیش از حدود ۱۰ نفر دشوار می‌شود.

برای EventStorming به چه چیزهایی نیاز دارید؟

EventStorming یک کارگاه کم‌فناوری محسوب می‌شود، زیرا با قلم و کاغذ انجام می‌شود—البته مقدار زیادی کاغذ. برای تسهیل یک جلسهٔ EventStorming به موارد زیر نیاز دارید:

فضای مدل‌سازی

نخست به یک فضای مدل‌سازی بزرگ نیاز دارید. یک دیوار کامل که با کاغذ بزرگ پوشانده شده باشد بهترین فضا را فراهم می‌کند، همان‌طور که در شکل ۱۲-۱ منبع دیده می‌شود. Whiteboard بزرگ هم قابل استفاده است، اما باید تا جای ممکن بزرگ باشد؛ در این کارگاه واقعاً به همهٔ فضای ممکن نیاز خواهید داشت.

Sticky Noteها

سپس به تعداد زیادی Sticky Note با رنگ‌های متفاوت نیاز دارید. این برگه‌ها مفاهیم مختلف دامنهٔ کسب‌وکار را نمایش می‌دهند و همهٔ شرکت‌کنندگان باید بتوانند آزادانه آن‌ها را اضافه کنند؛ بنابراین برای همه و در رنگ‌های کافی برگه داشته باشید. رنگ‌هایی که به‌طور سنتی در EventStorming استفاده می‌شوند در بخش بعد شرح داده خواهند شد. بهتر است در صورت امکان همین قرارداد رنگ را رعایت کنید تا با کتاب‌ها و آموزش‌های EventStorming موجود سازگار بمانید.

ماژیک

برای نوشتن روی Sticky Noteها به ماژیک نیاز دارید. باز هم تجهیزات نباید گلوگاه اشتراک دانش باشند؛ باید برای همهٔ شرکت‌کنندگان به اندازهٔ کافی ماژیک وجود داشته باشد.

خوراکی

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

اتاق

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

فرایند EventStorming

یک کارگاه EventStorming معمولاً در ۱۰ مرحله اجرا می‌شود. در هر مرحله، مدل با اطلاعات و مفاهیم بیشتری غنی می‌شود.

مرحلهٔ ۱: اکتشاف بدون ساختار (Unstructured Exploration)

EventStorming با طوفان فکری دربارهٔ Domain Eventهای مرتبط با دامنهٔ کسب‌وکار مورد بررسی شروع می‌شود. Domain Event چیزی جالب است که در کسب‌وکار رخ داده است. مهم است که Domain Eventها را با زمان گذشته بیان کنیم، زیرا رویدادها چیزهایی را توصیف می‌کنند که قبلاً اتفاق افتاده‌اند؛ این موضوع در شکل ۱۲-۲ نمایش داده شده است.

در این مرحله، همهٔ شرکت‌کنندگان تعدادی Sticky Note نارنجی برمی‌دارند، هر Domain Eventی که به ذهنشان می‌رسد روی آن می‌نویسند و برگه را روی سطح مدل‌سازی می‌چسبانند.

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

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

مرحلهٔ ۲: خط‌های زمانی (Timelines)

اکنون شرکت‌کنندگان Domain Eventهای تولیدشده را مرور می‌کنند و آن‌ها را بر اساس ترتیبی که در دامنهٔ کسب‌وکار رخ می‌دهند مرتب می‌کنند.

مرتب‌سازی باید با «Happy Path Scenario» آغاز شود: جریانی که یک سناریوی موفق کسب‌وکار را توصیف می‌کند.

وقتی Happy Path کامل شد، می‌توان سناریوهای جایگزین را اضافه کرد؛ برای مثال مسیرهایی که در آن‌ها خطا رخ می‌دهد یا تصمیم‌های تجاری متفاوتی گرفته می‌شود. شاخه‌شدن جریان را می‌توان با دو جریان جداشونده از Event قبلی یا با پیکان‌هایی روی سطح مدل‌سازی نشان داد، همان‌طور که در شکل ۱۲-۳ آمده است.

این مرحله همچنین زمان اصلاح Eventهای نادرست، حذف موارد تکراری و البته افزودن رویدادهای جاافتاده است.

مرحلهٔ ۳: نقاط درد (Pain Points)

پس از مرتب شدن Eventها روی خط زمانی، از این نمای گسترده برای شناسایی نقاطی در فرایند استفاده کنید که نیازمند توجه‌اند. این نقاط ممکن است Bottleneck، مرحلهٔ دستیِ نیازمند خودکارسازی، مستندات مفقود یا دانش دامنهٔ از دست‌رفته باشند.

صریح کردن این ناکارآمدی‌ها مهم است تا در ادامهٔ جلسه یا پس از پایان آن بتوان به‌آسانی به آن‌ها برگشت و رسیدگی کرد. Pain Pointها با Sticky Note صورتی که به شکل لوزی چرخانده شده علامت‌گذاری می‌شوند، همان‌طور که در شکل ۱۲-۴ نشان داده شده است. مثال شکل به فقدان دانش دامنه دربارهٔ نحوهٔ مقایسهٔ قیمت بلیت هواپیما در فرایند رزرو اشاره می‌کند.

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

مرحلهٔ ۴: رویدادهای محوری (Pivotal Events)

وقتی خط زمانی Eventها با Pain Pointها تکمیل شد، به دنبال Eventهای مهم کسب‌وکار بگردید که نشان‌دهندهٔ تغییر Context یا Phase هستند. به این‌ها Pivotal Event گفته می‌شود و با یک خط عمودی، Eventهای قبل و بعد از رویداد محوری را از هم جدا می‌کنند.

برای مثال، «Shopping Cart Initialized»، «Order Initialized»، «Order Shipped»، «Order Delivered» و «Order Returned» تغییرهای مهم در فرایند ثبت سفارش هستند؛ شکل ۱۲-۵ نمونه را نشان می‌دهد.

Pivotal Eventها می‌توانند نشانه‌ای از مرزهای بالقوهٔ Bounded Context باشند.

مرحلهٔ ۵: Commandها

Domain Event چیزی را توصیف می‌کند که قبلاً رخ داده است، اما Command چیزی را بیان می‌کند که باعث Event یا جریان Eventها شده است. Commandها عملیات سیستم را توصیف می‌کنند و برخلاف Domain Eventها به صورت امری بیان می‌شوند. برای مثال:

• Publish campaign
• Roll back transaction
• Submit order

Commandها روی Sticky Note آبی روشن نوشته می‌شوند و پیش از Eventهایی که می‌توانند تولید کنند روی فضای مدل‌سازی قرار می‌گیرند. اگر Command توسط Actor با Role مشخص اجرا شود، اطلاعات Actor روی Sticky Note کوچک زرد به Command اضافه می‌شود، همان‌طور که شکل ۱۲-۶ نشان می‌دهد. Actor یک User Persona در دامنهٔ کسب‌وکار است؛ مانند Customer، Administrator یا Editor.

طبیعتاً همهٔ Commandها Actor متناظر ندارند. اطلاعات Actor را فقط جایی اضافه کنید که مشخص باشد. در مرحلهٔ بعد، Entityهای دیگری را به مدل اضافه می‌کنیم که می‌توانند Commandها را Trigger کنند.

مرحلهٔ ۶: Policyها

تقریباً همیشه Commandهایی در مدل وجود خواهند داشت که Actor مشخصی ندارند. در این مرحله به دنبال Policyهای خودکارسازی می‌گردیم که آن Commandها را اجرا می‌کنند.

Automation Policy سناریویی است که در آن یک Event باعث اجرای Command می‌شود. به عبارت دیگر، با وقوع Domain Event مشخص، Command به‌طور خودکار اجرا می‌شود.

روی سطح مدل‌سازی، Policyها با Sticky Note بنفش نمایش داده می‌شوند که Event را به Command متصل می‌کند؛ شکل ۱۲-۷ نمونهٔ Policyای را نشان می‌دهد که با مشاهدهٔ Event «Shipment Approved»، Command «Ship Order» را Trigger می‌کند.

اگر Command فقط در صورت برقرار بودن معیار تصمیم خاصی باید اجرا شود، معیار را روی Sticky Note Policy صریحاً بنویسید. برای مثال، ممکن است پس از Event «Complaint Received» نیاز به Trigger کردن Command «Escalate» باشد، اما فقط اگر شکایت از مشتری VIP آمده باشد؛ در این حالت شرط «Only for VIP customers» را مستقیماً روی Policy ثبت کنید.

اگر Event و Command روی فضای مدل‌سازی از یکدیگر دور باشند، می‌توان آن‌ها را با پیکان متصل کرد.

مرحلهٔ ۷: Read Modelها

Read Model نمایی از دادهٔ دامنه است که Actor برای تصمیم‌گیری دربارهٔ اجرای یک Command از آن استفاده می‌کند. این View می‌تواند یکی از Screenهای سیستم، یک Report، Notification یا چیزی مشابه باشد.

Read Modelها با Sticky Note سبز نمایش داده می‌شوند—مانند برگهٔ «Shopping Cart» در شکل ۱۲-۸—و توضیح کوتاهی از منبع اطلاعات مورد نیاز برای پشتیبانی از تصمیم Actor روی آن‌ها نوشته می‌شود. چون Command بعد از مشاهدهٔ Read Model توسط Actor اجرا می‌شود، روی سطح مدل‌سازی Read Model پیش از Command قرار می‌گیرد.

مرحلهٔ ۸: سیستم‌های خارجی (External Systems)

این مرحله دربارهٔ افزودن External Systemها به مدل است. External System هر سیستمی است که جزئی از دامنهٔ در حال بررسی نیست. یک سیستم خارجی می‌تواند Command را اجرا کند (ورودی) یا دربارهٔ Eventها اطلاع دریافت کند (خروجی).

External Systemها با Sticky Note صورتی نمایش داده می‌شوند. در شکل ۱۲-۹، CRM به‌عنوان سیستم خارجی اجرای Command «Ship Order» را Trigger می‌کند. وقتی Shipment تأیید می‌شود، Event از طریق یک Policy به CRM اطلاع داده می‌شود.

تا پایان این مرحله، هر Command باید یا توسط Actor اجرا شود، یا توسط Policy Trigger شود، یا از طرف External System فراخوانی گردد.

مرحلهٔ ۹: Aggregateها

وقتی همهٔ Eventها و Commandها نمایش داده شدند، شرکت‌کنندگان می‌توانند دربارهٔ سازمان‌دهی مفاهیم مرتبط در Aggregateها فکر کنند. Aggregate، Command دریافت می‌کند و Event تولید می‌کند.

Aggregateها با Sticky Note زرد بزرگ نمایش داده می‌شوند؛ Commandها در سمت چپ و Eventها در سمت راست آن قرار می‌گیرند، همان‌طور که شکل ۱۲-۱۰ نشان می‌دهد.

مرحلهٔ ۱۰: Bounded Contextها

آخرین مرحلهٔ جلسهٔ EventStorming این است که به دنبال Aggregateهایی بگردید که با یکدیگر ارتباط دارند؛ یا چون قابلیت‌های بسیار مرتبطی را نمایش می‌دهند، یا چون از طریق Policyها به هم Coupled شده‌اند. گروه‌های Aggregateها نامزدهای طبیعی برای مرزهای Bounded Context هستند؛ نمونه‌ای از این تجزیه در شکل ۱۲-۱۱ دیده می‌شود.

گونه‌ها (Variants)

Alberto Brandolini، خالق EventStorming، فرایند EventStorming را «راهنما» می‌داند، نه مجموعه‌ای از قوانین سخت. شما آزادید فرایند را آزمایش کنید تا «دستور پختی» را پیدا کنید که برای شما بهترین نتیجه را می‌دهد.

در تجربهٔ نویسنده، هنگام معرفی EventStorming در یک سازمان بهتر است ابتدا تصویر بزرگ دامنهٔ کسب‌وکار با اجرای مراحل ۱ (اکتشاف آشفته/بدون ساختار) تا ۴ (Pivotal Eventها) بررسی شود. مدل حاصل دامنهٔ گسترده‌ای از کسب‌وکار شرکت را پوشش می‌دهد، پایه‌ای قوی برای Ubiquitous Languageها ایجاد می‌کند و مرزهای احتمالی Bounded Contextها را مشخص می‌سازد.

پس از به‌دست آوردن تصویر بزرگ و شناسایی فرایندهای مختلف کسب‌وکار، برای هر فرایند مرتبط یک جلسهٔ اختصاصی EventStorming برگزار می‌شود؛ این بار همهٔ مراحل اجرا می‌شوند تا فرایند به‌طور کامل مدل شود.

در پایان یک جلسهٔ کامل EventStorming، مدلی خواهید داشت که Eventها، Commandها، Aggregateها و حتی Bounded Contextهای احتمالی دامنهٔ کسب‌وکار را توصیف می‌کند. با این حال، همهٔ این‌ها مزایای جانبی‌اند. ارزش واقعی EventStorming خود فرایند است: اشتراک دانش میان ذی‌نفعان مختلف، هم‌راستا شدن مدل‌های ذهنی آن‌ها از کسب‌وکار، کشف مدل‌های متعارض و در نهایت شکل‌گیری Ubiquitous Language.

مدل نهایی می‌تواند مبنایی برای پیاده‌سازی Event-Sourced Domain Model باشد. تصمیم دربارهٔ انتخاب این مسیر به دامنهٔ کسب‌وکار بستگی دارد. اگر Event-Sourced Domain Model را انتخاب کنید، مرزهای Bounded Context، Aggregateها و نقشهٔ Domain Eventهای مورد نیاز از قبل در اختیار شماست.

چه زمانی از EventStorming استفاده کنیم؟

این کارگاه را می‌توان به دلایل گوناگون برگزار کرد:

ساخت Ubiquitous Language

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

مدل‌سازی فرایند کسب‌وکار

EventStorming راهی مؤثر برای ساخت مدل فرایند کسب‌وکار است. چون بر Building Blockهای DDD تکیه دارد، برای کشف مرز Aggregate و Bounded Context نیز مفید است.

بررسی Requirementهای جدید

می‌توان از EventStorming برای اطمینان از هم‌فهمی دربارهٔ قابلیت جدید و آشکار کردن Edge Caseهایی استفاده کرد که Requirementها پوشش نداده‌اند.

بازیابی دانش دامنه

دانش دامنه ممکن است با گذر زمان از دست برود، به‌ویژه در سیستم‌های Legacy که نیازمند Modernization هستند. EventStorming دانشی را که افراد مختلف در اختیار دارند در یک تصویر منسجم ادغام می‌کند.

کشف راه‌های بهبود فرایند موجود

نمای End-to-End از یک فرایند، دید لازم برای تشخیص ناکارآمدی‌ها و فرصت‌های بهبود را فراهم می‌کند.

Onboard کردن اعضای جدید تیم

برگزاری EventStorming همراه با اعضای جدید، روشی عالی برای گسترش دانش دامنهٔ آن‌ها است.

در کنار دانستن زمان مناسب استفاده، باید بدانیم چه زمانی EventStorming انتخاب خوبی نیست. اگر فرایند کسب‌وکار بسیار ساده یا بدیهی باشد—مثلاً فقط مجموعه‌ای از مراحل ترتیبی و بدون منطق یا پیچیدگی جالب—EventStorming احتمالاً ارزش کمتری ایجاد می‌کند.

نکات تسهیل‌گری (Facilitation Tips)

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

هنگام معرفی Domain Event، Command، Actor و عناصر دیگر، یک Legend ساخته می‌شود که در شکل ۱۲-۱۲ منبع نمایش داده شده است؛ Legend با همان Sticky Noteهای رنگی و Labelها ساخته می‌شود تا شرکت‌کنندگان Color Code را به خاطر بسپارند. این راهنما باید در تمام طول کارگاه در معرض دید همه باشد.

پویایی گروه را زیر نظر بگیرید

با پیشرفت کارگاه، دنبال کردن انرژی و پویایی گروه مهم است. اگر سرعت و مشارکت کاهش یافت، ببینید آیا می‌توان با پرسیدن سؤال دوباره فرایند را فعال کرد یا زمان عبور به مرحلهٔ بعد رسیده است.

EventStorming یک فعالیت گروهی است؛ بنابراین مطمئن شوید واقعاً به‌صورت گروهی انجام می‌شود. همه باید فرصتی برای مشارکت در مدل‌سازی و بحث داشته باشند. اگر می‌بینید بعضی شرکت‌کنندگان از گروه فاصله گرفته‌اند، با پرسیدن سؤال دربارهٔ وضعیت فعلی مدل آن‌ها را درگیر کنید.

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

EventStorming از راه دور

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

با آغاز همه‌گیری COVID-19 در سال ۲۰۲۰، جلسات حضوری ناممکن شد و EventStorming نیز دیگر نمی‌توانست دقیقاً به شکل اولیه اجرا شود. ابزارهای متعددی تلاش کردند همکاری و تسهیل EventStorming از راه دور را ممکن کنند. در زمان نگارش کتاب، مهم‌ترین نمونه miro.com بود. هنگام اجرای آنلاین باید صبورتر باشید و ارتباط کم‌اثرترِ ناشی از فاصله را در نظر بگیرید.

تجربهٔ نویسنده همچنین نشان می‌دهد Remote EventStorming با تعداد کمتر شرکت‌کنندگان مؤثرتر است. در حالی که جلسهٔ حضوری می‌تواند تا حدود ۱۰ شرکت‌کننده داشته باشد، نویسنده جلسات آنلاین را به پنج نفر محدود می‌کند. اگر افراد بیشتری باید دانش خود را مشارکت دهند، می‌توان چند جلسه برگزار و سپس مدل‌های حاصل را مقایسه و ادغام کرد.

هر زمان شرایط اجازه داد، به EventStorming حضوری بازگردید.

جمع‌بندی

EventStorming کارگاهی مبتنی بر همکاری برای مدل‌سازی فرایندهای کسب‌وکار است. گذشته از مدل‌های نهایی، مزیت اصلی آن اشتراک دانش است. تا پایان جلسه، شرکت‌کنندگان مدل‌های ذهنی خود را از فرایند کسب‌وکار همگام می‌کنند و نخستین گام‌ها را به سوی استفاده از Ubiquitous Language برمی‌دارند.

EventStorming شبیه دوچرخه‌سواری است: یادگیری آن با انجام دادن بسیار آسان‌تر از خواندن دربارهٔ آن در کتاب است. با این حال، کارگاه سرگرم‌کننده و تسهیل آن آسان است. برای شروع لازم نیست «کمربند سیاه EventStorming» داشته باشید؛ جلسه را برگزار کنید، مراحل را دنبال کنید و در حین انجام کار یاد بگیرید.

تمرین‌ها

1. چه کسانی باید به جلسهٔ EventStorming دعوت شوند؟
   1. Software Engineerها
   2. Domain Expertها
   3. QA Engineerها
   4. همهٔ ذی‌نفعانی که دربارهٔ دامنهٔ کسب‌وکار مورد بررسی دانش دارند
2. چه زمانی فرصت مناسبی برای برگزاری EventStorming است؟
   1. برای ساخت Ubiquitous Language
   2. برای بررسی یک دامنهٔ کسب‌وکار جدید
   3. برای بازیابی دانش از دست‌رفتهٔ پروژهٔ Brownfield
   4. برای معرفی اعضای جدید تیم
   5. برای کشف راه‌های بهینه‌سازی فرایند کسب‌وکار
   6. همهٔ پاسخ‌های بالا درست‌اند
3. از یک جلسهٔ EventStorming چه خروجی‌هایی می‌توان انتظار داشت؟
   1. درک مشترک بهتر از دامنهٔ کسب‌وکار
   2. پایه‌ای قوی برای Ubiquitous Language
   3. کشف نواحی ناشناخته در درک دامنهٔ کسب‌وکار
   4. یک مدل مبتنی بر Event که می‌تواند برای پیاده‌سازی Domain Model استفاده شود
   5. همهٔ موارد بالا ممکن‌اند، اما به هدف اولیهٔ جلسه بستگی دارند

شکل‌ها و جدول‌های منبع

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