مسعود بهرامی
تبدیل پیچیدگیهای بیزنس به مدلهای نرمافزاری از طریق فرآیندهای فشردهسازی دانش
در پروژههای نرمافزاری بزرگ، بزرگترین چالش، فاصله میان آنچه کسبوکار انجام میدهد(و میخواهد) و آنچه مهندسان میسازند است. این فاصله ناشی از حجم عظیم، پراکنده و گاه حتی متناقض دانش کسبوکار(همان دومین خودمون) است.
مفهوم عصارهگیری از دانش دومین یا Knowledge Crunching در چارچوب DDD، فرآیندی است که در آن دانش پراکنده متخصصان دامنه (Domain Experts) از طریق تکنیکهای تعاملی و تحلیلی، فشرده، پالایش و به مدلهای ساختاری (Bounded Contexts) تبدیل میشود. این مقاله به بررسی دقیق این فرآیند، ابزارهای آن و نقش آن در جلوگیری از شکست پروژههای پیچیده میپردازد.
بحران ابهام دامنه (Domain Ambiguity)
بسیاری از پروژههای نرمافزاری به این دلیل شکست نمیخورند که کد بدی دارند، بلکه به این دلیل شکست میخورند که درک ناکافی یا اشتباهی از واقعیت کسبوکار دارند. در سازمانهای بزرگ، دانش بیزنس در ذهن افراد، در اسناد قدیمی، در ایمیلها و در فرآیندهای شفاهی پخش شده است.این وضعیت باعث بروز پدیدههای زیر میشود.
Ubiquitous Language ناقص: توسعهدهندگان و متخصصان بیزنس از کلمات یکسانی برای مفاهیم متفاوت استفاده میکنند.
طراحی نرمافزار تنیده شده در هم (Big Ball of Mud): به دلیل عدم درک مرزها، تمام بخشهای سیستم به هم گره میخورند.
مفهومKnowledge Crunching در DDD، تلاش آگاهانه برای بازگرداندن نظم به این آشوب است. این فرآیند، جراحیِ دانش برای رسیدن به مدلهای دقیق است.
مبانی مفهومی Knowledge Crunching در کالبد DDD
در DDD، ما با دو سطح طراحی طراحی روبرو هستیم. طراحی در سطح Strategic و طراحی در سطح Tactical. Knowledge Crunching دقیقاً در نقطه اتصال این دو قرار دارد.
انتقال از اطلاعات به مدل
در کسبوکار، ما با اطلاعات سر و کار داریم. مثلاً، مشتری این سفارش را ثبت کرد. اما در نرمافزار، ما به مدل نیاز داریم .مثلاً، کلاس Order که قوانین کسبوکاری و باید و نبایدهای یک سفارش را در خود دارد.
Knowledge Crunching فرآیندِ تبدیلِ Events (رویدادهای کسبوکار) به مدلهای نرمافزاری است. میدانیم که نقطه اتصال فضای مسئله(Problem Space) و فضای راهحل(Solution Space) در DDD هم دقیقا همین مدلسازی است.
کاهش بار شناختی (Cognitive Load)
یک مدل پیچیده، بار ذهنی تیم را بالا میبرد. Knowledge Crunching با تقسیم کردن یک دامنه بزرگ به Bounded Contexts کوچکتر، دانش را فشرده کرده و مدیریت آن را ممکن میسازد.
چگونه به کمک Knowledge Crunching دانش را فشرده کنیم؟
فرآیند Knowledge Crunching یک فعالیت تکنفره نیست، بلکه یک رویکرد Collaborative (همکاریمحور) است. برای این نوشته خیلی طولانی نشود، زیاد وارد جزئیات نخواهم شد. اما میتوان بصورت تیتروار اشاره کرد که knowledge crunching بصورت کلی، شامل مراحل زیر است.
مرحله ۱: استخراج رویدادها به کمک Event Storming یا Exploratory Domain Discovery
اولین گام در Crunching، تخلیه تمام دانش موجود در ذهن متخصصان است. برای اینکار میتوان از رویکردهای Collaborative Modeling and Designing(CoMo) از جمله ایونت استورمینگ و Exploratory Domain Discovery کمک گرفت. مثلا، در جلسات Event Storming، تمام آنچه در دامنه رخ میدهد (Domain Events) روی یک دیوار (یا بوم دیجیتال) قرار میگیرد.
هدف از این مرحله، تبدیل دانش پنهان به دانش آشکار.
مرحله ۲: شناسایی الگوها و خوشهها (Clustering)
در این مرحله، رویدادهای مرتبط با هم گروهبندی میشوند. مثلاً تمام رویدادهایی که مربوط به پرداخت هستند، در یک خوشه قرار میگیرند. این کار، فشردهسازی اولیه است. در حقیقت این اولین فرصت برای فشردهسازی و تفکیک و تقسیم فضای مسئله، جهت غلبه و سوار شدن بر پیچیدگی آن است.
مرحله ۳: تعریف مرزها (Defining Bounded Contexts)
در این مرحله، ما تصمیم میگیریم که کجا یک مدل به پایان میرسد و مدل دیگر شروع میشود. این حساسترین بخش Crunching است؛ جایی که ما مرزهای معنایی را تعیین میکنیم تا از تداخل مفاهیم جلوگیری شود.
مرحله ۴: تدوین زبان مشترک (Ubiquitous Language)
در این مرحله، اصطلاحات نهایی شده و برای هر خوشه (Context)، یک دیکشنری دقیق تعریف میشود. دانشِ فشرده شده حالا در قالب کلمات و مدلهای مشخص، قابل انتقال به کد است.
رویکردها اجرای موثرتر Knowledge Crunching
برای اجرای بهتر Knowledge Crunching، از دو رویکرد اصلی استفاده میشود:
رویکرد بالا به پایین (Top-Down / Strategic)
تمرکز بر شناسایی Context Map است. ما ابتدا نگاه میکنیم که چگونه بخشهای مختلف سازمان (مثلاً فروش، انبار، ارسال) با هم تعامل دارند. این رویکرد برای مدیریت پیچیدگیهای سازمانی بسیار حیاتی است.
رویکرد پایین به بالا (Bottom-Up / Tactical)
تمرکز بر جزئیات مدل است. ما به سراغ Aggregateها، Entities و Value Objects میرویم تا مطمئن شویم قوانین بیزنس (Invariants) به درستی در مدل فشرده شدهاند.
مثال کاربردی: سیستم مدیریت یک ایرلاین
اجازه بدید یک مثال بزنیم تا موارد بالا بهتر درک شود. فرض کنید میخواهیم سیستم یک ایرلاین را طراحی کنیم. دانش این سیستم بسیار پراکنده است.
حالت آشوب قبل از Crunching
همه چیز به هم وصل است. کلاس `Passenger` در بخش رزرو بلیط با کلاس `Passenger` در بخش بار و خدمات پذیرایی یکی است. اگر ویژگی جدیدی به مسافر اضافه شود، کل سیستم دچار مشکل میشود.
فرآیند Knowledge Crunching
با اجرای Event Storming، رویدادهایی مثل `FlightBooked` ،`BagChecked` ،`BoardingPassed` استخراج میشوند. سپس سراغ مرحله بعد میرویم یعنی Clustering. رویدادهای مربوط به بلیط در یک خوشه، و رویدادهای مربوط به بار در خوشهای دیگر قرار میگیرند.
پس از این مرحله، اقدام به تعیین مرزبندی سیستم و تعیین BCs خواهیم کرد.
Context رزرو: تمرکز بر `Booking` و `Payment`. در اینجا مسافر فقط یک `CustomerID` است.
Context پذیرایی: تمرکز بر `Luggage` و `Weight`. در اینجا مسافر یک `PassengerID` با مشخصات فیزیکی است.
نتیجه این طراحی این است که، دانش فشرده شده و مرزها مشخص شدند. حالا تیم رزرو میتواند بدون نگرانی از تغییرات در سیستم بار، کد خود را توسعه دهد.
اهمیت و نقش استراتژیک یک Knowledge Crunching صحیح در موفقیت پروژه
باید اشاره و تاکید کرد که Knowledge Crunching صرفاً یک تمرین مدلسازی نیست، بلکه یک مدیریت ریسک است که منجر به مزیتهای زیر خواهد شد.
کاهش هزینه تغییر (Lower Cost of Change)
طبیعی است وقتی مرزها مشخص باشند، تغییر در یک بخش، باعث فروپاشی بخشهای دیگر نمیشود.
همگامی تیم توسعه و کسبوکار
وقتی مدل نرمافزار، بازتاب دقیق دانش بیزنس باشد، فاصله بین ذهن متخصص و کد از بین میرود.
مقیاسپذیری تیمها (Team Scalability)
با تقسیم دانش به Contextهای کوچک، میتوان تیمهای مختلف را به صورت مستقل روی هر بخش کار داد (مطابق با اصول Team Topologies).
چالشها و ریسکهای اجرایی
همانند هر مفهوم دیگری در نرمافزار، این فرآیند هم بهدور از مخاطرات و ریسکها نیست. شاید بتوان در پایان این نوشتار، بصورت خلاصه چالشهایی که باید قبل از وارد شدن به این فرآیند آنها رو شناخت، را بصورت زیر اشاره کنم.
مقاومت متخصصان دامنه. متخصصان بیزنس معمولاً وقت زیادی برای نشستن پای تخته و بحث کردن ندارند.
خطر بیشمدلسازی (Over-modeling). تلاش برای فشرده کردن بیش از حد جزئیات غیرضروری که منجر به پیچیدگی در کد میشود.
تغییرات ناگهانی کسبوکار. اگر مدل کسبوکار مدام در حال تغییر باشد، فرآیند Crunching میتواند به یک گلوگاه (Bottleneck) تبدیل شود.
Knowledge Crunching قلب تپنده طراحی DDD است. این فرآیند، هنرِ تبدیل صدای جمعیت (دادههای پراکنده بیزنس) به مدلهای یکپارچهی نرمافزاری است. معمارانی که بر این فرآیند تسلط دارند، نه تنها سیستمهایی پایدارتر میسازند، بلکه پل ارتباطی حیاتی میان دنیای بیزنس و دنیای تکنولوژی هستند. برای موفقیت در پروژههای بزرگ، باید از کدنویسی فراتر رفت و به سمت مهندسی دانش حرکت کرد.
