Event storming

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

به شیوه سابق مهندسین نرم افزار از UML استفاده میکردن (زبان مدلسازی یکنواخت) اما دو ایراد اساسی داشتیم اول اینکه در این رویکرد متخصصین کسب و کار حذف میشدند یعنی کسانی که در شناخت حوزه بشدت کارآمد هستند و دوم اینکه عدم در نظر گرفتن گلوگاه‌ها، وابستگی‌ها و داینامیک بودن پروژه می باشد این مسئله درست هستش که میتوان دیاگرام‌های بیشتر و بیشتری طراحی و این برای مهندسین نرم افزار خوب و بهتر بود اما همچنان مورد اول پا برجا بود

در دنیای DDD ما نیاز به رویکردی جدید و مدرنتر داشتیم که بتوان موارد زیر رو رفع کرد:
۱- فضای مسئله و راه حل‌ها
۲- شناخت و یافتن BC یا همان مرزهای محدود
۳ـ جلسات منفعل با BR یا همان متخصصان کسب و کار
۴- فرار از مدلسازی‌های نامناسب
۵- تهیه کردن لیست نیازمندی ها
۶- دست یافتن سریع به یک زبان مشترک


همیشه دیدگاه اشتباهی راجب DDD وجود دارد اینکه این رویکرد فقط برای سیستم‌هایی جوابگو هستش که در ابتدای راه و ساختن قراردارد اما این یک اشتباه هست اتفاقا این رویکرد برای سیستم‌های قهوه‌ای (امیدوارم منظور نویسنده از قهوه‌ای را گرفته باشید) بهتر پاسخ میدهد

در سال ۲۰۱۳ یک روش خلاقانه با عنوان event storming معرفی شد که پایان هرآنچه که در بالاتر مطرح کردیم رو ختم کرد

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


با توجه به اینکه مطالب مربوط به event storming زیاد و گوناگون است لذا این بخش از کتاب رو بهتر هستش خودتون با سرچ کردن و خوندن مقالات متنوع یاد بگیرید

#DDD
#domain_driven_design

@code_crafters