پست‌های انتشارات مهندسی نرم افزار، معماری و طراحی سیستم

آموزش Domain Driven Design - طوفان رویداد (بخش اول)

صادق شجری — Mon, 29 Jul 2024 10:43:43 +0330

در فصول گذشته، آموختیم که شناخت و درک مساله واقعی تا چه میزان با اهمیت است. همچنین در مفهوم Ubiquitous Language عمیق شدیم و شرح دادیم که فقط یک لغتنامه از اصطلاحات نیست، بلکه رفتار سیستم است که در قالب کلمات شرح داده شده اند.اما واضح نشد که چگونه شروع کنیم تا دانش موجود در دامنه را قطعه بندی کنیم و چگونه ارتباطات خود را با متخصصین دامنه تشدید کنیم تا فضای مساله را بهتر درک نموده و دید بهتری نسبت چیزی که می خواهیم بسازیم بدست آوریم.اغلب دیده می شود که توسعه دهندگان، دامین را به عنوان مجموعه ای از نیازمندی ها می شناسند. ما قبلا در مورد این موضوع بحث کردیم و دیدیم که این وابستگی به نیازمندی ها معایب خود را دارند. بنابراین، ما باید زبان خود را با صحبت مستقیم با متخصصین دامین بهبود بخشیم و جلساتی را با آنها سازماندهی کنیم. برخی از افراد به این جلسات آمده و برای 2 الی 3 ساعت باهم صحبت می کنند. درباره بسیاری از مسائل بحث خواهد شد و بینش های فراوانی به شما افزوده می شود، اما خروجی حداقلی از هر نوع از مدل سازی بدست می آید. در این مرحله حتما می توانید نمودار های UML طراحی کنید، اما چگونه شخصی که در آن کسب و کار است، متوجه این نمودار شود؟ همچنین شروع به یادداشت نکات برای آموختن آنچه نیاز دارید می کنید. اما از آنجا که مفاهیم ضمنی و مبهم زیادی وجود دارد که پایه های سیستم آینده شما را تشکیل می دهند، باعث می شود درک آن بسیار سخت باشد.چندین مشکل اساسی وجود دارد که نیاز به رفع آنها داریم:شفافیت در طول صحبت ها. وقتی افراد زیادی در مورد یک موضوع واحد به شکل های مختلف صحبت می کنند، فرضیات را بوجود می آورند.داشتن یک زبان مدلسازی شده که افراد آن را درک کنند. نمودار های UML در اینجا جزو گزینه ها محسوب نمی شود چرا که باکس ها و فلش هایی که در آن استفاده می شود، نماد حقیقت نیستند. پس افراد شروع به سردرگمی کرده و به صرف زمان برای شفاف سازی معانی چیزها می پردازند.افراد زیادی را به طور همزمان درگیر کنید. در جلسات سنتی، فقط یک نفر می تواند پیام را بدرستی منتقل کند، در حالیکه بقیه افراد باید فقط ساکت بوده و گوش دهند. به محض اینکه افراد زیادی همزمان شروع به صحبت کنند، دیگر مکالمه مفیدی شکل نمی گیرد. با فرض افرادی با علایق و زمینه های مختلف که در جلسه حاضر هستند، پس از مدتی ممکن است علاقه شان را از دست داده و خسته شوند.یافتن راهی برای ارائه اصطلاحات، رفتارها، فرایندهای مدل و تصمیمات، و نه ویژگی ها و دیتاها.در سال 2003، آلبرتو برندولینی، روشی را ابداع کرد و آن را طوفان رخداد (Event Storming) نامید. روشی که تلاش دارد مشکلاتی که در بالا مطرح شد را برطرف کند. ما در این فصل در مورد این روش خواهیم آموخت.مدلسازی زبانایده اصلی پشت طوفان رویداد این است که یک نماد مدل سازی ساده ارائه می دهد که به منظور مصور سازی رفتار سیستم به گونه ای که همه متوجه آن شوند، استفاده می شود. این رویکرد، شفافیت ایجاد می کند، تعامل را افزایش می دهد و افرادی را درگیر می کند که به هر دلیلی در مورد مشارکت در جلسه مدل سازی یا نوشتن چیزی روی وایت برد، مضطرب بوده اند.با در نظر گرفتن رفتار، بعنوان جنبه اصلی دانش دامین، تمامی تمارین طوفان رویداد در مورد این است که متوجه شویم آن کسب و کار چگونه کار می کند. بطور کلی، می توانیم این طور فرض کنیم که هر سیستم در هر لحظه از زمان، در یک حالت خاص یافت می شود. این حالت خاص می تواند با تعاملاتی که بازیگران آن سیستم دارند، تغییر یابد. عملیاتی که این بازیگران انجام می دهند، مسبب تغییر وضعیت سیستم شده، بنابراین می توانیم ببینیم که اتفاقی رخ داده و اکنون باید با این وضعیت جدید سروکار داشته باشیم.بیایید نگاهی به یک مثال ساده از کسی که قبض اش را توسط اینترنت بانک پرداخت می کند، کنیم:سلسله رخدادها برای فرایند پرداخت (ساده شده)همانطور که می بینید، از نگاه شخصی که پرداخت می کند، مبلغ پولی که در حسابش داشت، کاهش پیدا می کند، پرداخت با موفقیت انجام می گردد و قبض پرداخت شده محسوب شده و می توان آن را دور انداخت! از نگاه دریافت کننده، قبض زمانی پرداخت شده محسوب می شود که پول را دریافت کنند و بتوانند این پرداخت را با یک قبض باز (پرداخت نشده) توسط شناسه قبض مطابقت دهند.هر عملی توسط بازیگران این سیستم، باعث برخی تغییر حالات می شوند. سفارش پرداخت ایجاد شده و ثبت شد. مبلغ قبض از حساب پرداخت کننده کسر شد. این مبلغ به حساب دریافت کننده افزوده شد. قبض "پرداخت شده" علامت گذاری شد. تمامی این عملیات، حقیقت های واقعی زندگی هستند و تا زمانی که ماشین زمان نداشته باشیم، نمی توانیم آنها را بازگردانیم. اگر دریافت کننده تشخیص دهد که قبض قبلا پرداخت شده بوده است، آن ها نمی توانند چیزی را بازگردانند. آنها مجبور به بازگشت پول در یک رخداد پرداخت جدید هستند.این حقایق بعنوان رخداد های دامین شناخته می شوند. این ها مفاهیم اولیه اما در عین حال مهمی هستند که طوفان رویداد با آنها سر و کار دارد. به همین دلیل هست که این اسم برای آن انتخاب شده است. ایده رخدادهای دامین برای هیچ کس غریبه نیست. حقایق واقعی زندگی چیزهایی هستند که مردم می توانند به راحتی آن را درک کنند. آن ها چیزی هستند که اتفاق می افتد، نه چیزی که برخی می خواهند آن را انجام دهند. نه یک ویژگی و نه ظاهر یک دکمه در سایت. هر رخداد دامین نشان دهنده یک حقیقت است. یک تغییر در سیستمی که می خواهیم آن را مدل سازی کنیم.بنابراین، اولین بخش از مدلسازی زبان ما ایجاد مفهوم رخدادهای دامین است. هر مفهومی در طوفان رویداد، توسط یک برچسب با رنگی مشخص نشان داده می شود. رنگ در اینجا ضروری است. چرا که هرچه جلوتر رویم و افکار بیشتری برای مدل سازی بیاوریم، به آن ها نیاز داریم تا ایده های یکسان در طول مدل را به منظور رفع سردرگمی نمایش دهیم. پیشنهاد اصلی که آلبرتو دارد، استفاده از برچسب های نارنجی برای نمایش رخداد های دامین است. ساده ترین حالت ممکن از مدل می تواند چیزی شبیه به این باشد:از نقطه کوچکی شروع کرده و از آنجا ادامه دهیدتصویر بالا نمایانگر دو رخداد دامنه است که به ترتیب رخ می دهند. اول، یک مشتری توسط کارت اعتباری خود پرداخت را انجام می دهد، سپس سفارش تایید می شود. می توانیم تشخیص دهیم که این مربوط به یک دامین ایکامرس است. هیچ چیز عجیب و خاصی در مورد متونی که در برچسب استفاده می شود وجود ندارد، بجز یک قاعده بسیار مهم. رخداد ها باید فاعل و فعل داشته باشند. فعل باید در آخرین عبارت به کار رود که نشان دهنده این است که چیزی رخ داده است.اگر به مثال پرداخت قبض برگردیم، می توانیم تلاش کنیم تا رخدادهایی که آنجا رخ می دهد را بیابیم:رخدادها در یک تایم لاین قرار گرفته اندچندین نکته در تصویر بالا وجود دارد که احتمالا به سرعت متوجه آنها شدید. اولین نکته این است که رخدادهای دامین، یک تایم لاین را دنبال می کنند. این کار تقریبا منطقی است، چرا که رخدادها بیانگر تغییرات بعدی در سیستم هستند، لذا در یک ترتیب مشخصی اتفاق می افتند. بعنوان مثال، پرداخت قبل از ثبت شدن نمی تواند تایید شود. برخی از موارد ممکن است به صورت موازی اتفاق بیفتد، مانند بدهکار و بستانکار کردن حساب های پرداخت کننده و دریافت کننده به صورت همزمان، به محض تأیید دستور پرداخت، که ممکن است به این معنی باشد که بانک اطمینان دارد که پرداخت کننده دارای وجوه کافی برای تکمیل پرداخت است.نکته دوم این است که ما فقط یک سیستم در اینجا نداریم. در واقع ما کل فرایند را مدلسازی کرده ایم. اما حداقل سه بخش وجود دارند که به وضوح می توانیم آنها را تشخیص دهیم. اینترنت بانک کاربر که سفارشات پرداخت را ایجاد و ثبت می کند. واحد پشتیبانی بانک که تراکنش را تکمیل می کند. و سیستم مطابقت پرداخت به قبض برای دریافت کننده که حتی ممکن است بصورت دستی انجام شود.تصویر سازی (Visualization)همانطور که در بخش قبل دیده شد، مدل ساده ای که طراحی کردیم، ارزش های فراوانی برای افراد درگیر در ورکشاپ رونمایی کرد. نه تنها تلاش کردیم آنچه در طول پرداخت یک قبض بوجود می آید را شناسایی کنیم، بلکه کل جریان را در یک تایم لاین ترسیم کردیم و قادر شدیم بخش هایی از فرایند را که در هر سیستم فیزیکی رخ می دهد را به خوبی شناسایی کنیم.تصویرسازی یکی از قوی ترین جنبه های تکنیک های مدل سازی است. طوفان رویداد نیز از این رویه مستثنی نیست. به محض اینکه چیزی را به مدل خود اضافه می کنیم، می توانیم منطق پشت این کار را بیان کنیم، جای اینکه فقط کلمات را هجی کرده و دستانمان را تکان دهیم!زمانی که افراد تصویر کلی از آنچه رخ می دهد را می بینند، ممکن است سوالاتی را که با عبارت چه می شود اگر؟ مطرح می کنند.چه می شود اگر پول کافی در حساب نباشد؟ چه می شود اگر شماره رفرنس قبض صحیح نباشد؟ چه می شود اگر حساب دریافت کننده صحیح نباشد؟ چه می شود اگر ...؟ اینجاست که مشخص می شود مدل ساده ما در انتها به این سادگی باقی نخواهد ماند. عبارت دسترسی اکتشافی را به یاد آورید، آیا آنچه می بینید، تمام چیزی است که وجود دارد؟ ما از درک اولیه خود بعنوان پایه ای برای نگاهی ساده به دنیا استفاده می کنیم. همه چی آنطور که باید، عمل می کند. هیچ استثنایی وجود ندارد، مردم برای اشتباه کردن برنامه ریزی نمی کنند. اما دنیا کمی پیچیده تر از این است. موارد پیش بینی نشده نسبت به جریان منطقی رخداد ها بیش از آن چیزی است که ما به آن فکر کرده باشیم. تمامی این موارد پیش بینی نشده و استثنائات زمانی که چیزها مصور می شوند، بیشتر نمایان می شوند و چون چراغی در تاریکی می مانند.یک مساله ای اینجا پیش می آید، که می تواند برای کسانی که بهترین تلاششان را برای ساخت یک مدل رخداد انجام می دهند زیان آور باشد. تصور کنید چنین ورکشاپی در یک اتاق جلسه برگزار می شود. معمولا افراد بین یک میز نشسته و صحبت می کنند. همانطور که قبلا گفتیم، این روشی نیست که طوفان رویداد از آن استفاده می کند. ما از افراد انتظار داریم که در اتاق حرکت داشته باشند و فعالانه در بحث مشارکت کنند. این مشارکت ممکن است به صورت همزمان در نقاط مختلفی از اتاق رخ دهد. پس ما نیاز به فضای بیشتری داریم. اما این همه فضایی نیست که به آن نیاز داریم. داشتن نگاه درست به مدل فرایندی ساده گذشته. اگر چه توافق داریم که مدل ما فقط مسیر شادی (happy path) را در نظر گرفته و استثنائات (edge cases and exceptions) را نادیده گرفته، اما می دانیم که دنیای واقعی این گونه برخورد نمی کند. نمودار ساده ما هم اکنون نیز فضای افقی ای را گرفته است. حالا فرض کنید سناریوهای دنیای واقعی اینگونه مدل سازی شوند. در واقع یک وایت برد 2 3 متری برای شما نمی تواند به درستی خدمات دهی کند!تصور کنید مدل شما چیزی شبیه به این است:برای یک سیستم منطقی پیچیده، شما به فضای بزرگتری نیاز داریدقسمت هایلایت شده عکس، وایت برد شماست. اما مدل شما در آن جا نمی شود. همانطور که آلبرتو گفته است، مشکل من بزرگ تر است!چه زمانی رخ می دهد وقتی که فضای کافی روی تخته وجود نداشته باشد؟ افراد بعنوان یک منبع ترسناک به فضای باقیمانده نگاه می کنند. این فضا گرانبها شده و افراد شروع به ذخیره فضا می کنند. برخی رخداد ها تبدیل به بی اهمیت می شوند پس داخل وایت برد وارد نمی شوند. برخی رخداد ها ثانویه محسوب شده و ارزش نگاه کردن ندارند. در نهایت، مدل سازی ما قربانی حفظ کمی فضا در وایت برد می شود!این اتفاق، اتفاقی طبیعی است و مغز ما اینگونه کار می کند. اگر برخی محدودیت ها را ببینیم، مهم نیست نتیجه کارمان چقدر بد و نامطلوب شود، ما فعالیت هایمان را بر اساس فضای فیزیکی که داریم محدود می کنیم. اگر یک فضای محدود برای مدلسازی دارید، انتظار دریافت یک مدل محدود و ناقص را داشته باشید. پس، نسبت به این موضوع آگاه باشید و فضایی برای مدل سازی ایجاد کنید که برای همه مشارکت کنندگان جلسه طوفان رویداد کافی باشد.پایان بخش اول

آموزش Domain Driven Design - زبان و زمینه

صادق شجری — Tue, 23 Jul 2024 13:00:54 +0330

در آغاز این فصل، اشاره ای به تفاوت های زبانشناسی در یک زبان کردیم. ما از زبان انگلیسی که در امریکا و انگلیس استفاده می شد مثال زدیم که جملات مشترک ممکن است معانی مختلفی در این دو کشور داشته باشند. مثال های فراوانی از این دست وجود دارد. همین اتفاق در زبان گروههای حرفه ای نیز مشاهده می شود. جایی که افراد اصطلاحات تخصصی را توسعه می دهند. مثال هایی از این موارد هم اشاره کردیم.این مثال ها، اهمیت تعریف دقیق معانی کلمات را مشخص می کنند. اجتناب از سردرگمی در واقع یکی از اهداف شناسایی زبان مشترک و فراگیر (Ubiquitous Language) است.فهم این نکته اهمیت زیادی دارد که زبان مشترک و فراگیر تنها داخل زمینه (context) خودش اعتبار دارد. یک زمینه متفاوت با زبان متفاوتی تعریف می شود. یک اشتباه رایج در درک زبان مشترک و فراگیر وجود دارد که عبارت مشترک و فراگیر اشاره به یک زبان واحد برای کل کسب و کار، سازمان یا دامین دارد. در حالی که اینطور نیست. مشترک و فراگیر بودن آن، افقی نیست. بلکه عمودی است. هر زمینه ممکن است زبان خاص به خود را داشته باشد،در عین حال این امکان وجود دارد تمامی لایه ها در این زمینه؛ یک زبان مشترک و فراگیر واحد را به اشتراک گذارند.بیایید نگاهی به یک مثال کلاسیک از عبارت محصول (product) در زمینه های متفاوت از دامین خرید و فروش بیاندازیم:محصول، در زمینه های مختلفاگر چه ما در یک دامین مشترک هستیم، اما واژه Product معانی و مفاهیم مختلفی در هر یک از زمینه های مشخص شده دارد: فروش (Sales): برای فروشندگان، محصول به معنی قیمت فروش و حتی حاشیه سود است. جایی که شرکت از آنجا پول بدست می آورد و سایر خصوصیات محصول اهمیتی ندارد.خرید (Purchasing): اگر یک محصول را خریداری کرده باشیم به نیت فروش مجدد آن، ما بیشتر از همه به قیمت خرید علاقمند هستیم. اینکه چقدر از یک کالای در انبار تامین کننده موجود است؟ و اینکه آن کالاها در چه فاصله زمانی بعد از سفارش به ما خواهند رسید؟فهرست موجودی (Inventory): ما بیشتر از همه علاقمند به دانستن تعداد هر چیزی در انبارمان هستیم. اگر موجودی کالایی کمتر از حد انتظار باشد، می توان تاریخ تخمینی برای سفارش و دریافت مجدد کالا را در این زمینه (context) در نظر گرفت. در اینجا ما احتمالا برخی خصوصیات داخلی محصول مانند شماره انبار آن محصول را نیز تعریف می کنیم.انبار (Warehouse): نیاز به مدیریت فضایی دارد که برای نگهداری محصولات مورد نیاز است. پس افرادی که در این زمینه حظور دارند، نیاز دارند تا زمان رسیدن کالاهای جدید به انبار را بدانند. و اینکه چگونه باید آنها را دسته بندی کنند. و در کجا هر محصول را ذخیره سازی کنند.همانطور که می بینید، اگر چه ما یک اصطلاح رایج مانند محصول را داریم، اما دپارتمان های مختلف از یک دامین مشترک یا سازمان نیز خصیصه های مشترک بسیار کمی از مفهوم آن در بخش های خودشان دارند و هر زمانی که در هر بخش به معنی و مفهوم آن عمیق می شویم، مشاهده می شود که ویژگی های خاص به آن بخش به آن کلمه اعتبار و مفهوم متفاوت می دهد.مثال بالا نشاندهنده این است که حتی در یک دامین خاص، زمینه های مختلفی می تواند وجود داشته باشد که زبان در آنجا تغییر نموده و برخی اوقات این تغییرات بسیار فاحش هستند. اما چه اتفاقی رخ می دهد اگر ما از یک معنی در تمام زمینه ها استفاده کنیم؟ این کار باعث می شود که مسائل، کمتر صریح باشند. درجات ابهام با هر زمینه جدید، افزایش می یابد و باعث می شود در تفکیک و شناسایی آنها در زمینه های مختلف به مشکل بر بخوریم. اینها باعث ایجاد یک مدل غیرشفاف می شوند و در نتیجه مسبب کد مبهم می شود. جائیکه نیاز پیدا می کنیم مشخص کنیم که منظور ما از آن کلمه در آن زمینه، دقیقا چیست؟ مخلوط کردن زمینه های مختلف در یک محیط کاری نیز شما را به سمت چیزی به نام تغییر زمینه (context switching) هدایت می کند. جرالد وینبرگ در کتاب خود اینطور تخمین می زند که بالا رفتن تعداد پروژه هایی که یک فرد روی آن کار می کند، باعث افت شدید بهره وری آن شخص بدلیل همین تغییر زمینه می شود.کاهش بهره وری بدلیل تغییر زمینه هاافزودن یک پروژه به پروژه های کنونی به معنی کاهش 20 درصدی بهره وری شما می باشد. اگر تعداد زمینه های مختلف شما به 5 برسد، مقدار زمانی که مفید روی کارها می گذارید، به شدت کاهش می یابد. زمان زیادی از شما صرف این مساله می شود که متوجه شوید کدام زمینه متعلق به پروژه یا تسک جاری شماست.این قاعده فقط برای پروژه ها معتبر نیست. ممکن است زمانیکه تعمیم (generalization)، بر دقت و عدم ابهام غالب شود، پدیده تغییر زمینه بوجود آمده و به همان اندازه که گفته شد، بر روی عملکرد شما تاثیر گذار باشد. در مثالی که در مورد Product بیان شد، اگر ما تمام خصوصیات Product که از هر زاویه دیدی وجود دارد را در یک کلاس تعریف کنیم، کار با چنین آبجکتی مستلزم تلاش بیشتر و همچنین تلاش برای درک آن بخش از Product با توجه به زمینه ای که در حال کار با آن هستیم، دارد. بنابراین، با اینکه داریم بر روی یک چیز کار می کنیم، دچار تغییر زمینه مخفی شده ایم و به مضرات آن دچار خواهیم شد.فرض کنید که تمرکزگرایی و تعمیم پذیری، چیزهای خوبی بودند و بسیاری از شرکت ها، کلاس هایی (God classes) مانند Customer یا Product ایجاد می کردند که شامل تمام خصوصیات ممکن از همه زوایای مختلف بود. علاوه بر تغییر زمینه ای که رخ می داد، معایب دیگری نیز بوجود می آمد.یکی از معایب واضح، این است که در طول یک چرخه عمر مشخص از چنین آبجکتی در سیستم، همه خصوصیات مورد نیاز ما نیستند. برای مثال، محصول از رده خارج شده، هیچ ویژگی ای ندارد که مرتبط با بخش فروش باشد. اما چون ما یک کلاس برای همه خصوصیات داریم، مجبور هستیم مقادیر خالی را برای تمامی محصولات ایجاد کنیم. چنین رویکردی ما را به سطح بالایی از سردرگمی می رساند چرا که ما به سختی متوجه این خواهیم شد که چرا این خصوصیات، بی استفاده هستند. اشتباهی در سیستم هستند و یا یک وضعیت معمولی با توجه به وضعیت آبجکت هستند؟مساله دیگر این است که ناچارا این کلاس ها دارای وابستگی های زیادی می شوند. احتمالا دیتامدل هایی را دیده اید که سیستم با تمام پیچیدگی هایش، فقط یک دیتابیس SQL بزرگ دارد که جداول آن رفرنس های زیادی به یکدیگر دارند. می توانیم اینطور فرض کنیم که جدولی مانند Product با جداولی چون Order,ShoppingCart, Catalogue,Invoice,PurchaseInvoice, Return, CreditNote و ... رفرنس دارد. این مدل به سرعت درهم می شود و نگهداری آن بسیار دشوار می شود. برخی اوقات، اوضاع از این هم خراب تر می شود. مثلا فرض کنید مشخصات یک محصول تغییر می کند. اما نباید مشخصات محصول برای خرید های قبلی که از آن انجام شده دچار تغییر شود. هر سفارش باید کپی خودش از محصول خریداری شده را در لحظه خرید، ضبط کند.به اندازه کافی علت اینکه باید مراقب فراموش نکردن زمینه ها باشیم را متوجه شدیم. زبان مشترک و فراگیر (Ubiquitous Language)، همیشه باید بدون ابهام، صریح و مختص به زمینه (context) باشد. به محض اینکه حس کردید معانی کلمات شروع به تغییر در بخش های مختلف سیستم کردند، باید هشداری در درون شما را فعال کند که در حال عبور از مرزبندی های آن زمینه هستید.هنگام بحث در مورد کاربران، زمینه مطرح می شود. توسعه دهندگان مایل اند به مردم به عنوان کاربر نگاه کنند. این اصطلاح خیلی مبهم است. تا آنجائیکه تقریبا می توان تضمین داد که زمانی که در مورد کاربران در حال صحبت هستیم، در حال تغییر بین زمینه های مختلف هستیم.به دامین نمونه خودمان بازگردیم. جایی که توسعه دهندگان در حال بحث در مورد چگونگی امتیازدهی کاربران به معاملات خودشان هستند. آنها به این فکر کردند که اگر مردم بتوانند به یکدیگر امتیاز دهند، به آنها در ایجاد اعتماد در جامعه شان در نرم افزار کمک می کند. برخی از آنان متوجه شدند که از کلمات << کاربر، فروشندگان، آنها که می فروشند، آنها که می خرند و خریداران>> دارند به جای هم استفاده می کنند. وقتی که اصطلاح عمومی کاربر استفاده می شد، همیشه نیاز به شفاف سازی داشت: این کاربر چه نقشی در آن لحظه دارد ایفا می کند؟ همزمان، وقتی کاربران را به نام های خریدار یا فروشنده صدا می زدند، ابهامی بوجود نمی آمد و نیاز به شفاف سازی نبود.پس از این، گروه متوجه شد که المنت های جدیدی از Ubiquitous Language را کشف کرده و شروع به استفاده از این اصطلاحات کرد. این کار بینش خوبی به آنها داد که زمانی زیادی از بحث آنها را در مورد مدل ها صرفه جویی نمود و ابهام در کد را نیز از بین برد.همزمان، تفکیک مردم به خریدار یا فروشنده در قسمت اعتبار سنجی (authorization) سیستم منطقی به نظر نمی رسید. آنها فقط کاربر هستند که می توانند به سیستم لاگین کرده و برخی عملیات انجام دهند. مانند بروزرسانی پروفایلشان. بدون توجه به اینکه بین خریدار بودن یا فروشنده بودن آن فرد در سیستم، تمایزی قائل شویم. این خود یک زمینه دیگر است که کلمه user ابهامی ندارد و صریح است.بعدا، مجددا آنها گونه دیگری از کاربران را یافت کردند که نیاز به مدل شدن در سیستم داشت. جائیکه کاربران شروع به گرفتن نقش های مختلف می کردند. و مجددا ابهام بوجود آمد تا آنها شروع کردند به استفاده از اصطلاحاتی چون administrator، support assistant و reviewer. زمینه جدیدی یافت شد و مدل جدید برای آن ایجاد شد که از زمینه های دیگر با توجه به معانی کلمات استفاده شده در آنها تفکیک گشت.

آموزش DDD- مثال- زبان دامنه برای تبلیغات طبقه بندی شده

صادق شجری — Sat, 20 Jul 2024 19:58:29 +0330

در بخش های قبلی، در مورد پروژه تستی که در طول دوره به تکمیل آن خواهیم پرداخت، صحبت کردیم. اینکه پروژه ای شبیه به پلتفرم دیوار که افراد می توانند ابزار و لوازم اضافه خود را به دیگران که به این لوازم نیاز دارند بفروشند یا اهدا کنند.برنامه نویسان ما در مورد جریان انتشار تبلیغات طبقه بندی شده در حال بحث و گفتگو بودند. آنها از فرایند ایجاد تبلیغات عبور کرده و به نقطه ای رسیدند که کاربر دکمه انتشار را می زند. ما و متخصص دامنه، فهمیدیم که نباید بلافاصله بعد از زدن این دکمه، آن آگهی انتشار پیدا کند، چرا که ممکن است دارای محتوای نامناسب باشد. آنها تصمیم گرفتند که فرایند تاییدی را تعریف کنند که پس از کلیک بر روی انتشار آغاز می گردد و پس از گذراندن این فرایند، تبلیغ در وب سایت به کاربران نمایش داده می شود.توسعه دهندگان به سرعت تصمیم گرفتند یک خصیصه Status به کلاس دامین ClassifiedAd اضافه کنند. نوع این خصیصه Enum است که نشان دهنده وضعیت های مختلف فرایند بازبینی و انتشار تبلیغ است. همچنین این خصیصه بعدا می توان بعنوان وضعیت هایی که هنوز برای ما ناشناخته هستند و ممکن است بعدا بوجود بیایند نیز استفاده شود. از آنجائیکه آنها می خواهند رفتارها را در مدل دامین پیاده سازی کنند، متد UpdateStatus را نیز به کلاس اضافه کردند که شبیه به کد زیر شد: https://gist.github.com/msadeqshajari/7b4e0f3fe66c9b6ab619b3a239062af0 حالا که متد، یک رخداد دامین را نیز منتشر می کند، سایر اجزای سیستم می توانند این رخداد را subscribe کنند و عملیات مقتضی با آن را انجام دهند.ما در ادامه بخش ها در این دوره بیشتر در مورد event ها و command های دامین صحبت می کنیم و توضیح می دهیم. پس بعد از اینکه کاربر بر روی انتشار کلیک کرد، کد زیر اتفاق می افتد:ad.UpdateStatus(ClassifiedAdStatus.Published);و بعد از اینکه بازبینی به اتمام رسید، تبلیغ فعال می شود:ad.UpdateStatus(ClassifiedAdStatus.Activated);به نظر همه چیز قابل قبول است. کلاس ClassifiedAd ما یک state machine است. یعنی جائیکه نمونه هایی از این کلاس در چرخه عمر یک تبلیغ از یک وضعیت به وضعیت دیگر حرکت می کنند. با این وجود، ما هدف را گم کردیم. زبان ما عجیب شد! بجای اینکه بگوئیم ما می خواهیم که تبلیغ را منتشر کنیم، می گوئیم، ما وضعیت تبلیغ را تغییر می دهیم. بجای فعال سازی تبلیغ، مجددا می گوئیم وضعیت تبلیغ را تغییر می دهیم!بعد از چندین تغییر در سیستم، به نظر می رسد که کد درست کار می کند: https://gist.github.com/msadeqshajari/6699a80339497ac8e996e9c086cff269 این قطعه کد، کدی نیست که انتظار داشتیم برای این متد ساده نوشته شده باشد. این متد، وظایف زیادی را متحمل شده است و بلاک های منطقی این کد به سختی با یکدیگر در ارتباط هستند. اما مشکل بزرگتر زمانی پدیدار می شود که می خواهیم رخداد دامین را مدیریت کنیم: https://gist.github.com/msadeqshajari/b9d106b0dac3ea4c8611a68ba32b6719 تعداد عملیات های کنترل جریان کد رشد پیدا می کند و بیشتر رفتار کد اکنون توسط بروزرسانی وضعیت ها هدایت می شود. چیزی که در ابتدا یک عملیات مشخص و کوچک بر روی یک خصیصه از آبجکت دامین به نظر می رسید. هدف ما که بروزرسانی وضعیت بود، منحل شده است و هر قسمت از کد باید به شدت کنترل شود تا اثرات جانبی مخربی نداشته باشد. اکنون ریسک آسیب به رفتارهای کنونی با افزودن کدهای جدید، جدی شده است.صحبت هایی که با متخصص دامنه شده بود نیز معانیشان را از دست دادند. بجای استفاده از عباراتی چون - اگر محتوای مخربی یافت شد، ما تبلیغ را مخفی می کنیم و گروه نظارتی خود را مطلع می کنیم- تبدیل شد به -اگر محتوای مخربی یافت شد، تمام تبلیغات با وضعیت MaliciousContentDetected را درخواست می کنیم و از سرویس نوتیفیکیشن برای رساندن یک پیام به کاربرانی که نقش نظارتی دارند استفاده می کنیم.-معانی موجود در زبان، پشت مفاهیم فنی گم شدند و با عباراتی کلی و عمومی مانند وضعیت و پیام ترکیب شدند.تیم تصمیم گرفت که کد را بازنویسی کرده و از زبان مدل متناسب استفاده کند. خروجی کار آنها این کد بود: https://gist.github.com/msadeqshajari/f0485b7a5e49bae2ea576443f334557c اکنون، همچنین می توانیم کنترلگر رخداد دامین را نیز به شکل زیر بازنویسی کنیم: https://gist.github.com/msadeqshajari/6d336646dbed8aa2396fc2313cea742b سپس برای مدیریت تبلیغاتی که محتوای نامناسب داشتند، می توانیم یک کنترلگر رخداد جدید ایجاد کنیم: https://gist.github.com/msadeqshajari/7d017c66a59a0109780374236a33c9d7 مثال های کوچک ما همچنین نشان می دهد که زبان دامین نمی تواند توسط ایجاد یک لغت نامه با اسامی ساخته شود. یک درک اشتباه درباره جمع آوری اسامی در یک لیست بلند بالا و صدا زدن این لیست بعنوان زبان دامین وجود دارد. این کار، مسیر درستی نیست و معمولا شما را به سمت یک مدل ضعیف (anemic model) هدایت می کند، که بعنوان یک آنتی پترن شناخته می شود. کلاس ها در این مدل، فقط شامل خصوصیات (properties) هستند و این خصوصیات همیشه توسط اسامی نام گذاری می شوند. اما بخش دیگری که اهمیت یکسانی با خصیصه ها دارد، رفتارهای یک مدل دامین هستند. اسامی بیانگر چیزهایی هستند که دامین با آنها اجرا می شود، اما افعال، چگونگی انجام کارها را نشان می دهند. بدون افعال، دامین ما با تغییرات خصیصه ها به سمت انجام عملیات های جادویی پیش می رود، بدون اینکه دلیل مشخصی برای آنها وجود داشته باشد. اما کدهای بالا واضحا بیانگر رفتار دامین توسط تعریف افعال بعنوان بخشی از زبان دامین هستند. این افعال (functions)، دقیق هستند، هدف را نشان می دهند و عملیات را شرح می دهند. در مثال گفته شده، ما نه تنها کد را بهبود بخشیدیم و درک صحیح تری از آنچه کد انجام می دهد و از مفاهیم موجود در آن بدست آوردیم، بلکه برخی اصطلاحات و مفاهیم جدیدی که مدل دامین ما از آن بهره می برد را کشف نمودیم. ما می توانیم از این اصطلاحات جدید در صحبت هایمان با متخصص دامین استفاده کنیم و ببینیم آیا آنها متوجه منظور ما می شوند یا خیر. برخی اوقات، ممکن است نگاهی عجیب به توسعه دهندگان کنند، چرا که در حال درک هیجان خود هستند چون آنها این اصطلاحات جدید رو از قبل می دانستند. زیرا این اصطلاحات مربوط به زبان آنهاست و آنها هیچوقت از این اصطلاحات در مکالمات بین کسب و کار و توسعه دهندگان استفاده نکرده بودند. پس چنین اقداماتی، نه تنها کد های بهتر و نزدیک تر به مدل کسب و کار واقعی را ایجاد کردند، بلکه ارتباطات بین متخصصین دامنه و توسعه دهندگان را نیز بهبود بخشیدند.با تبدیل مفاهیم ضمنی به مفاهیم صریح، نه تنها مفاهیم فراموش شده را در کدهایمان اکتشاف می کنیم، بلکه آن ها را به مدل دامین خودمان نیز می افزائیم. این بخش از کار ضروری است چرا که این زبان در تمام مدل هایی که مربوط به این دامنه هستند، استفاده می شود. هم مدل های کسب و کار و هم مدل های ذهنی، بصری و مفهومی مربوط به دامین در نمودار ها و در کدها. این الگوی استفاده از مفاهیم یکسان، یا به طور کلی، زبان یکسان در مراحل مختلف مدل ها در یک سیستم را زبان مشترک (Ubiquitous Language) می نامند.

آموزش Domain Driven Design - صریح سازی مسائل ذهنی

صادق شجری — Sat, 20 Jul 2024 10:55:39 +0330

زمانی که بر روی یک سیستم جدید شروع به کار می کنیم، نیاز به یاد گرفتن زیادی داریم. همانطور که در فصل قبل گفته شد، تقریبا بالاترین درجه جهالت و به طبع آن، پایین ترین سطح دانایی، زمانی رخ می دهد که تصمیمات فراوانی درباره آینده سیستم میگیریم. ما نه تنها از عدم دانایی در مورد دامین کسب و کار رنج می بریم، بلکه مجبور هستیم در محیطی با سطح بالایی از ابهام کار کنیم. قبل از اینکه در مورد زبان دامنه یاد بگیریم، از درک خودمان از موضوع استفاده می کنیم که غالبا بر اساس فرضیات ما هستند.حالتی را فرض کنید که با متخصصین دامنه در آغاز پروژه جلسه ای را برگزار می کنید. آنها تلاش می کنند تا مشکل خود را به شما شرح دهند و شما آرام آرام شروع به شناخت زبان آنها می کنید و پس از مدتی فکر می کنید که ایده اصلی آن ها را دریافت نموده و کم و بیش متوجه شده اید که چه کاری باید انجام دهید. در اینجا مهم است که بحث مربوط به سوگیری های شناختی و تاثیر گذاری آنها در تصمیم گیری که در فصل قبل اشاره شد را به یاد آورید. اولین و مهمترین ریسک در اینجا، این ریسک است: چیزی که می بینید، تمام چیزی است که وجود دارد. (ریسک دسترسی اکتشافی). شما دانش محدود خود را که از تجربیات گذشته تان نشات گرفته است را به کار می گیرید، سپس احساس می کنید کامل متوجه شده اید. در این نقطه معمولا از ما خواسته می شود که تخمین بزنیم و منطقا تخمین درستی نمی زنیم، چرا که سوگیری ها با ذهن ما بازی کرده و به ما توهم درک موضوع را داده اند.در چنین جلساتی، ما غالبا بر روی چیزی توافق می کنیم. سپس جلسه را ترک می کنیم. شاید پس از چند هفته مجددا در مورد مشخصات و حتی پروتوتایپ ها نیز صحبت کنیم. زمان گذر می کند و ما هنوز در همان اتاق هستیم که بودیم. هیچ کس راضی نیست. متوجه می شویم که ما بر روی یک چیز کاملا متفاوت توافق کرده بودیم. هر کسی تصویری در ذهن داشت که این تصویر ها باهم متفاوت بودند.اگر تصویرسازی نکنیم، روی چیزهای مختلف توافق می کنیمافراد ساعت ها صرف بحث کردن در مورد چیزهایی می کنند که فکر می کنند متفاوت هستند، اما در واقع یکی هستند. همچنین در مورد چیزی توافق می کنند که درک مشترکی درباره آن ندارند. این توافقات هیچوقت خوب پیش نمی روند. برای حل این مشکل، باید فرضیات را کنار گذاریم. باید چیزهای ضمنی (Implicit) را صریح (Explicit) کنیم.به نمونه زیر بعنوان یک سیستم مدیریت منابع انسانی واقعی نگاه کنید. در این فرم یک کارمند می تواند درخواست مرخصی کند.فرم ثبت مرخصیما در اینجا یک ساختار متداول را می بینیم که توسط یک برنامه نویس ایجاد شده است. همچنین می توانیم تصور کنیم که یک جدول SQL وجود دارد که دیتاهای وارد شده در این فرم را ذخیره سازی می کند. این جدول احتمالا ستون های StartDate، EndDate، HalfDay و Id کارمند را دارد. دقت کنید که یک دکمه Save هم داریم که در فرم هایی شبیه به این بسیار متداول هستند.با وجود اینکه این فرم کاملا درست به نظر می رسد، بیایید کمی در آن عمیق تر شویم:فیلد Start Date دارای ابهام است. آیا اشاره به زمانی دارد که فرم ثبت نام پر شده است یا زمانی است که کارمند بدلیل بیماری سر کار حاظر نشده است؟فیلد End Date ابهام بیشتری هم دارد. آیا این تاریخ آخرین روزی است که مرخصی گرفته شده است یا اولین روزی است که کارمند به محل کار باز گشته است؟فیلد Half Day می تواند برای هر کدام از دو تاریخ بالا اعمال شود. اما مشخص نشده است که برای کدام روز اتخاذ شده است.در نهایت، دکمه Save به ما هیچ نشانه ای از این که بعد از آن چه اتفاقی رخ خواهد داد، نداده است. ممکن است که فقط یک رکورد در دیتابیس افزوده شود و نیاز باشد بریم به کسی بگوئیم که برود آن را نگاه کند. یا ممکن است یک فرایند تایید مرخصی وجود داشته باشد که پس از فشردن Save به سرعت آغاز شود. آیا کارمند نیاز دارد تا بعد از ثبت فرم مرخصی، با ایمیل یا تلفن مدیر خط را در جریان بگذارد؟همانطور که می بینید، حتی در یک فرم کوچک با دو فیلد و یک چک باکس و دو دکمه، بسیاری از موارد ضمنی هستند. اگر کد پشت این فرم را تصور کنیم، تمام این ابهامات آن جا نیز نمایان خواهد شد. قبلا در مورد جدول احتمالی و ستون های آن جدول که نشان دهنده فیلدهای فرم هستند، صحبت نمودیم. تمامی خصوصیات موجود در کلاس های مدل دامین، آبجکت های دیتا مدل و سایر کدهای مرتبط با این فرم، همگی مبهم و ضمنی خواهند بود. همه چیز آنجا نیازمند یک توضیح هست. مانند اینکه "این تاریخ نشان دهنده زمانی است که کارمند به محل کار باز میگردد".حالا فرم بالا را با فرم زیر مقایسه کنید:فرم ثبت مرخصی که منطقی تر به نظر می رسددر این فرم، فیلد ها برای افراد معمولی که نیاز به حل معما یا خوانش راهنما برای پر کردن آن ها ندارند، منطقی تر به نظر می رسد. چیزهایی که در فرم قبل ضمنی بودند، اکنون صریح شده اند. همه چیز، از نام گذاری فیلدها تا دکمه ها (call to action)، معانی بهتری پیدا کردند. همچنین می توانیم تخمین بزنیم پشت این فرم، کدی شبیه به این وجود دارد: https://gist.github.com/msadeqshajari/322edaf592e1f0ce05027bd855b3b51b این کد بیانگر معانی و اصطلاحات مشترک با رابط کاربری است. بنابراین، نه تنها کاربر نهایی براحتی می تواند این فرم را تکمیل کند، بلکه یک رفیق برنامه نویس هم با خوشحالی می تواند این کد را بخواند، چرا که هدف به وضوح بیان شده است و تمامی مفاهیم، صریح هستند.جنبه دیگر صریح سازی ضمنی ها، ایجاد مفاهیم دامین است که در کد قابل رویت است. در کد بالا، دستور SendSickLeaveForApproval بیانگر مفهوم دامین دقیقی در کد است.

آموزش Domain Driven Design. زبان مشترک و فراگیر

صادق شجری — Thu, 18 Jul 2024 18:36:50 +0330

اتفاقی نیست که اریک ایوانز نویسنده اصلی کتاب DDD، آدرس سایتش را domainlanguage.com انتخاب کرده است. مفاهیم پایه ای DDD مانند زبان فراگیر (Ubiquitous Language) و مرزبندی زمینه ها (Bounded Context) بر اساس ایده زبان ایجاد شده اند. ممکن است این مساله برای برنامه نویسان تازه کار عجیب به نظر برسد. چرا که از نگاه آنها، تنها زبان با اهمیت، زبان برنامه نویسی است. ما فرض می کنیم که ترجمه زبان انسان ها به یک زبان برنامه نویسی، عصاره کار ماست. در حالیکه تا حدودی این مطلب صحیح است اما با بخش حیاتی کار روزانه ما بعنوان توسعه دهندگان نرم افزار فاصله دارد.دو نفر فقط در صورتی می توانند یکدیگر را درک کنند که بتوانند به یک زبان مشترک باهم سخن بگویند. لازم نیست این فهم مشترک حتما از طریق زبانی رخ دهد. ممکن است از طریق زبان اشاره یا حتی موسیقی به خوبی شکل گیرد. اما در هر صورت، نیاز است که درک مشترکی از روش ارتباطی با یکدیگر داشته باشند. در غیر این صورت، مشکل بوجود می آید. نه تنها آنها نیاز دارند تا با یک زبان مشترک باهم صحبت کنند، بلکه نیاز دارند تا در زمینه (context) آن زبان نیز مشترک باشند. برای مثال انگلستان و امریکا، هر دو به یک زبان صحبت می کنند. اما بعلت تفاوت زمینه ها ممکن است از یک جمله مختلف در این دو کشور دو برداشت متفاوت صورت گیرد.زبان دامینتقریبا هر صنعتی، زبان خاص به خود را توسعه داده است به گونه ای که فقط افراد داخل آن صنعت بطور کامل آن را درک می کنند. بعضی از کلمات آن زبان ها به کل جهان گسترش یافته اند، مانند دنیای خودرو که زبان ما را با اصطلاحاتی مثل گیربکس یا مثلا فروشگاه لوازم یدکی غنی تر کرده است. اصطلاح فروشگاه لوازم یدکی را اگر در بیرون از دامین خودرو نگاه کنیم، ممکن است دچار ابهام شویم. اما به محض اینکه دامین مشخص می شود، مبرهن می شود که منظور ما مثلا لوازم یدکی برای لوله کشی نیست، بلکه جایی است که ابزار مورد نیاز داخل خودرو در آن خرید و فروش می شود.مثال دیگری از صنعت های دیگر، صنعت نرم افزار است. زمانی که دو برنامه نویس در مورد پیاده سازی جزئیات یک سیستم پیچیده صحبت می کنند، افراد غیر برنامه نویس اطراف آنها چیزی از صحبت آن دو نفر دستگیرشان نمی شود و معمولا بحثی کسل کننده به نظرشان می رسد. عدم درک و شناخت همیشه باعث عدم علاقه و جذابیت می شود.دنیا از نگاه یک برنامه نویسصنعت نرم افزار را می توان از منظری، یک صنعت خاص در نظر گرفت. چرا که تلاشش این است که به رفع مشکل صنعت های مختلف کمک کند. امروزه تقریبا همه چیز نیاز یا تمایل به سطحی از اتوماسیون و نرم افزار دارد. این مورد همچنین بدین معنی است که افراد در کسب و کارهای مختلف، سراغ برنامه نویس های خود یا شرکت های نرم افزاری دیگر می روند و تلاش می کنند تا مشکل خود را به آنها به زبان خودشان عرضه نمایند. زمانی که این زبان به درستی درک نشود، مشکلات آغاز می شود.نیازمندی های فنی نوشته شده توسط متخصصینی که نه افرادی در آن صنعت هستند و نه برنامه نویس هستند، دیده شده که بعنوان چاهی برای نرم افزار های موفق عمل می کنند که در آن گرفتار می شوند. هربار که یک خروجی ناخوشایند به یک مشتری ناراضی می دهیم، نیازمندی ها را سرزنش می کنیم. پس از آن به مشتری می گوییم که نیازمندی ها را بهتر می نویسیم و تلاش می کنیم که جزئیات بیشتری را بررسی کنیم و به برنامه نویسان بابت هر جزئیات کوچکی نیز توضیحات کامل ارائه کنیم. این روند به سرعت باعث می شود که هر کس انگشت اتهام را به سمت شخص دیگری اشاره بگیرد و هیچ کس بابت هیچ چیز مسئولیت نخواهد پذیرفت.همانطور که در بخش اول گفته شد، لیست نیازمندی ها نه تنها فقط بر روی راه حل بجای مساله تمرکز دارند، بلکه تلاش دارند که زبان کسب و کار را به یک زبان فنی تر ترجمه کنند، بطوری که خوشایند برنامه نویسان باشد. در واقعیت، این کار بیشتر شبیه به یک تلفن شکسته است. سطوح بیشتری از ترجمه که به خطوط انتقالی اضافه شود، دیتای مرتبط کمتری به دریافت کننده می رسد.یکی دیگر از اثرات این ترجمه، کند نمودن سرعت ارتباط است. اگر برنامه نویسان به جزئیات بیشتری از کسب و کار نیاز داشته باشند، آنهم بدون اینکه خود کسب و کار را درک کرده باشند، درگیر شدن مترجم اجتناب ناپذیر خواهد شد. زیاد شنیده می شود که شخص مشخصی مانند معمار نرم افزار فقط اجازه صحبت با مشتری را دارد. سپس آنها نیازمندی های نرم افزار را به تحلیل گران کسب و کار می دهند و آنها این نیازمندی ها را به برنامه نویسان بیچاره واگذار می کنند! که عملا در این فرایند ترجمه گم شده اند.به همین خاطر است که درک کسب و کار، برای افرادی که برای ساخت یک راه حل خوب برای یک مشکل واقعی کسب و کار فعالیت دارند، الزامی می شود. درک کسب و کار و ارتباط با آن بدون نیاز به مترجم، نه تنها زمان ارتباط را کاهش می دهد، بلکه کیفیت این چنین ارتباطی را نیز به شدت افزایش می دهد.همزمان، همه می دانیم که دسترسی به افراد حاظر در یک کسب و کار که معمولا نقش مشتریان را برای ما ایفا می کنند، کار راحتی نیست. ممکن است نهایتا چند جلسه بتوانید با آنها برگزار کنید و اطلاعات حیاتی مورد نیاز برای دستیابی به ساخت یک سیستم که نیاز آنهاست را بدست آورید. در این حالت، وجود یک شخص خاص که مورد اعتماد کسب و کار است و به زبان آن ها صحبت می کند، بسیار کمک کننده است. باید اطمینان حاصل کنیم که این شخص همچنین برای تیم توسعه نیز مورد اعتماد است. این شخص را می توانید تحلیل گر کسب و کار یا مالک محصول صدا بزنید که اهمیت خاصی ندارد. مهم این است که این شخص قادر باشد با هر کسی به زبان خودشان صحبت کند، مانند یک مترجم سطح بالا که صحبت های یک رئیس جمهور را طوری ترجمه می کند که معنی کلمات و عبارات در ترجمه ضایع نشود. باز، هنوز هم بهترین رویکرد عدم وجود مترجم بین تیم توسعه و کسب و کار می باشد!مثلا بانکدار های شهر لندن، همیشه بدنبال توسعه دهندگانی هستند که قبلا از خدمات بانکی زیاد استفاده کرده باشند و همینطور در این شهر زندگی کرده باشند. آنها برای وقتشان ارزش قائلند و بدنبال کوتاه کردن زمان ارتباطات و مذاکرات هستند. پس شخصی که به زبان آنها آشنا باشد و به درک خوبی از کسب و کارشان رسیده باشد، برای آنها نسبت به کسی که برنامه نویس بهتر و با سابقه تری باشد، ارجحیت دارد.دامین نمونه یک اپلیکیشندر طول این دوره، ما یک اپلیکیشن نمونه را به منظور بکارگیری دانش و مهارت هایمان توسعه می دهیم. در این بخش، یک مقدمه برای شناخت دامنه کسب و کار گفته میشود، سپس در ادامه مباحث، جزئیات بیشتری در مورد دامین کسب و کار افزوده خواهد شد.دامینی که قصد داریم روی آن کار کنیم، یک سیستم فروش لوازم آنلاین برای اشخاص حقیقی است. ما اپلیکیشنی خواهیم ساخت که تبلیغات دسته بندی شده را منتشر کند بعلاوه چیزی که ممکن است برای پشتیبانی از این نوع فعالیت مورد نیاز باشد.اگر با اصطلاح های گفته شده خو نگرفتید، فرض کنید مجموعه ای از لوازم (شاید خرت و پرت!) که در انباری خانه تان دارید که ممکن است مایل به حتی دور ریختن آنها باشید. شما می توانید یک تبلیغ کوچک گذارید و افراد دیگر ممکن است به چیزی که شما نیاز ندارید، نیاز داشته باشند و آن را بخرند. حتی می توانید آنها را به رایگان به دیگران بدهید. سرویس های مشابهی مانند eBay وجود دارد. یا برای ما ایرانیها، کاری است که دقیقا پلتفرم هایی مانند دیوار و شیپور انجام می دهند.در بخش های بعدی، در جزئیات این دامین بیشتر غرق می شویم و به آهستگی و با درک مفاهیم و دانش های جدید نسبت به ساخت و توسعه آن اقدام می کنیم.

آموزش Domain Driven Design - دانایی در برابر جهالت!

صادق شجری — Wed, 17 Jul 2024 18:59:32 +0330

بیشتر برنامه نویسان تازه کار، فرض می کنند توسعه نرم افزار فقط تایپ کد است و زمانی که تجربه بیشتری در تایپ کردن کد بدست می آورند و با کلیدهای میانبر بیشتری از IDE آشنا می شوند و فریمورک ها و کتابخانه ها را بهتر درک می کنند، تصور می کنند تبدیل به توسعه دهندگان نینجا شده اند و می توانند نرم افزاری مانند اینستاگرام را در چندین روز بنویسند!اما واقعیت کاملا متفاوت است. پس از کسب مقداری تجربه و بعد از گذران چندین ماه یا حتی سال که ددلاین های غیر ممکن و اهداف غیر واقع بینانه را می بینند، افراد شروع به کم کردن سرعتشان می کنند. افراد شروع به درک این موضوع می کنند که نوشتن سریع کد بعد از دریافت یک مساله جدید احتمالا بهترین ایده نیست. غرق شدن در راه حل بجای درک صحیح مساله، بی اعتنایی به پیچیدگی های ضروری و اعمال سوگیری های شناختی، همه این فاکتورها در زمان توسعه نرم افزار تاثیر می گذارند. به محض کسب تجربه بیشتر و فراگیری از اشتباهات گذشته خودمان یا دیگران، خواهیم آموخت که ضروری ترین بخش نوشتن کد مفید و نرم افزار سودمند، دانایی در مورد فضای مساله ای (problem space) است که برای آن در حال ایجاد یک راه حل هستیم.دانایی در مورد دامینهمه دانش ها به یک اندازه در زمان ساخت یک فرایند نرم افزاری مهم و موثر نیستند. دانستن چگونگی کدنویسی با جاوا در دامین های مالی ممکن است تاثیر چندانی در نوشتن اپ iOS برای مدیریت بنگاه املاک نداشته باشد. البته قواعدی مانند clean code، DRY و ... با هر زبان برنامه نویسی که کار کنید، قطعا مفید خواهد بود. اما دانایی در مورد یک دامین ممکن است کاملا با نیازمندی های شما برای یک دامین دیگر متفاوت باشد.اینجا، جایی است که ما مفهوم دانایی دامین را مطرح می کنیم. دانایی دامین، دانش در مورد آن دامینی است که می خواهید نرم افزارتان را در آن اجرا کنید. اگر در حال ساخت یک سیستم خرید و فروش باشید، دامین شما دامین مالی خرید و فروش است. پس نیاز دارید تا در مورد خرید و فروش مقداری دانش بدست بیاورید تا متوجه حرف هایی که کاربران با شما یا با یکدیگر می زنند یا نیازهایی که مطرح می کنند، بشوید.تمام این موارد در فضای مساله هستند. اگر قادر نباشید تا حداقل اصطلاح فضای مساله را درک کنید، صحبت با کاربران آینده شما سخت یا غیرممکن خواهد بود. اگر مشکل عدم شناخت دامنه را داشته باشید، تنها منبع اطلاعاتی شما لیست خصوصیات سیستم (specification list) خواهد بود. اما در صورت شناخت دامین، یکی از اثرات، ایجاد اعتماد بین کاربر و برنامه نویس خواهد بود. وقتی این اعتماد ایجاد می شود، برنامه نویس بینش بهتری از مساله دریافت می کند و اشتباهاتش آسانتر بخشیده می گردد. با صحبت در مورد دامین با متخصصین دامین (domain experts) (کاربران سیستم یا مشتریان)، همچنین اعتبار دریافت می کنید و آنها به شما بعنوان همکار نگاه می کنند.دستیابی به این دانش، کار آسانی نیست. افراد در دامین های خودشان با گذر زمان زیادی متخصص شده اند و آنها توسط این تخصص گذران زندگی می کنند. توسعه دهندگان نرم افزار یا آنالیزورهای کسب و کار، کار دیگری انجام می دهند و آن دامین مشخص ممکن است برای آنها کم شناخته شده باشد یا بطور کامل ناشناخته باشد. هنر اصلی در دستیابی به دانش دامین از طریق همکاری موثر می باشد. متخصصین دامنه، منبع بی نهایت اعتماد در آن دامنه هستند. با این وجود، آنها ممکن است اینطور نباشند! برخی از سازمان ها، دانش را قطعه بندی می کنند و ممکن است تکه هایی از اطلاعات مورد انتظار شما در هر بخش از سازمان باشد که وظیفه شما دیدن همان تکه هاست.توصیه کلی در اینجا، صحبت با تعداد زیادی از افراد در داخل دامین است. از مدیریت کل مجموعه گرفته تا دامین های زیر مجموعه. در زیر تعدادی از راهها برای دستیابی به این دانش اشاره شده است:صحبت کردن، محبوب ترین روش است که می تواند در قالب جلسات متعدد باشد. با این وجود، این صحبت ها ممکن است در صورتی که خروجی واضحی نداشته باشد، شما را به بیراهه ببرد. اما هنوز هم در همین صحبت ها ارزش هایی از دامین نهفته است. نیاز دارید تا به دقت گوش دهید و سوالات زیادی بپرسید تا این ارزش ها نمایان شوند.مشاهده نیز یک تکنیک بسیار قدرتمند است. افراد حوزه نرم افزار نیاز دارند تا با درونگرایی خود مقابله کنند، از برج امنیت خود بیرون بیایند و به طبقه خرید و فروش، انبار، لابی هتل یا هرجایی که کسب و کار در آن فعال است وارد شوند. سپس با مردم صحبت کنند و ببینند آنها چگونه کار می کنند.داستان سرایی در مورد دامین، تکنیکی است که توسط گرف ها، فلش ها و مقدار کمی متن همراه با شمارش به ترتیبت عملیات بوجود می آید تا تعاملات مختلف داخل دامین را تشریح کند. این روش، معمولا آسان بوده و نیاز به توضیح فراوانی برای افراد مختلف درگیر در پروژه ندارد.طوفان فکری. طوفان فکری از یادداشت کن و یک رول کاغذ تشکیل می شود که تمام فعالیت های موجود در دامین را به شکلی متناسب مدل سازی می کند. این روش اجازه می دهد تا فعالیت ها، جریان های کاری، فرایندهای کسب و کار و... را کشف کنید. اغلب، این روش همچنین باعث در معرض قرار گرفتن ابهامات، فرضیات، اصطلاحات نامشهود، سردرگمی ها و بعضی وقت ها تداخلات و ناراحتی ها می گردد. به طور خلاصه، هر چیزی که در دانش دامین وجود دارد! در بخش های بعدی به طور مفصل در مورد این روش صحبت خواهیم کرد.پرهیز از جهالت...فیلیپ آرمور مقاله ای در سال 2000 با نام 5 سطح جهالت (five orders of ignorance) منتشر کرد. این مقاله نشان می دهد که افزایش دانش دامین و کاهش جهالت در مورد دامین، دو کلید اساسی برای ساخت نرم افزار سودمند است. این مقاله بر روی جهالت از دامین صحبت می کند و 5 سطح از آن را معرفی می کند:سطح صفر جهالت که عدم جهالت است. در این سطح شما هیچ جهالتی نسبت به دامین ندارید و بیشتر دانش در مورد آن چیزی که باید بدانید را دارا هستید. اولین سطح جهالت، عدم دانش است. زمانی رخ می دهد که چیزی نمی دانید اما این ندانستن را قبول کردید و می دانید که نمی دانید. شما می خواهید که دانش بیشتری کسب کنید و جهالت خود را به سطح صفر برسانید، بنابراین کانال هایی برای دستیابی به این دانش در اختیار دارید.دومین سطح، عدم آگاهی است. زمانی که نمی دانید که نمی دانید! غالبا زمانی رخ می دهد که یک لیست خصوصیات دریافت می کنید که راه حل را شرح داده است، بدون اینکه مشخص کند این راه حل تلاش می کند کدام مشکل را رفع کند. این سطح همچنین زمانی دیده می شود که افراد تظاهر به صلاحیت داشتن در مورد مساله ای می کنند که در واقع صلاحیت آن را ندارند، و حتی نسبت به آن بی اطلاع هستند. بسیاری از تصمیمات غلط در این سطح از جهالت رخ می دهد.سطح سوم، عدم پردازش است. در این مرحله، حتی نمی دانید که چگونه باید نسبت به عدم آگاهی خود مطلع شوید. در واقع راهی برای اینکه تشخیص دهید نمی دانید که چه چیزی را نمی دانید، یافت نمی کنید. در این مرحله انجام هر چیزی بسیار مشکل است چرا که ظاهرا هیچ راهی برای دسترسی به کاربران نهایی وجود ندارد. حتی امکان اینکه از آنها بپرسید که درک شما از مساله آنها صحیح هست یا خیر تا بتوانید وارد مرحله عدم آگاهی بشوید نیز وجود ندارد. در این مرحله تقریبا فهم مساله ای که می خواهید آن را حل کنید نیز غیر ممکن است.سطح چهارم، فرا جهالت است. این اتفاق زمانی رخ می دهد که شما چیزی در مورد 5 سطح جهالت نمی دانید!همانطور که می بینید، جهالت در برابر دانایی قرار می گیرد. تنها راه برای کاهش جهالت، افزایش دانایی و درک است. سطح بالای جهالت، چه آگاهانه باشد چه ناآگاهانه، شما را به سمت عدم دانایی و عدم درک مشکل می برد. بنابراین شانس ساخت راه حل اشتباه برای مشکل را بسیار افزایش می دهد.جهالت در مراحل آغازین، در بالاترین سطح قرار می گیرد.اریک ایوانز، پدر DDD، نمودار بالا را بعنوان در بند جهالت بودن تشریح می کند. نکته اینجاست که در شروع هر پروژه ای، ما در وضعیت کمترین دانش و بیشترین جهالت نسبت به آن قرار دایم. در حالیکه بسیاری از تصمیمات مهم درباره طراحی و معماری پروژه نیز در همین مراحل اولیه رخ می دهد. از آنجائی که این تصمیمات بر اساس اصول خاصی گرفته نشده اند، پس مشخصا بهینه ترین نخواهند بود.دن نورث پیش بینی می کند که ما در زمان شروع پروژه، در بهترین حالت، در سطح دوم جهالت قرار داریم. او توصیه می کند که ما تمام تلاش خود را در همان مراحل اولیه برای افزایش دانش نسبت به مساله انجام دهیم. با اینکه احتمال از قلم افتادن موارد زیادی وجود دارد که با پیشرفت پروژه می توان در مورد آنها نیز دانش کسب کرد. این فرایند یادگیری، فرایندی دائمی و تکرار شونده است.

آموزش Domain Driven Design، فرایند تصمیم گیری و سوگیری ها

صادق شجری — Sun, 14 Jul 2024 16:37:15 +0330

مغز انسان، حجم فراوانی از دیتا را در هر ثانیه پردازش می کند. ما بسیاری از اعمال را بر پایه غریزه و عادت و به طور اصطلاحا auto pilot انجام می دهیم. سایر نواحی فعالیت های مغزی، شامل تفکر، یادگیری و تصمیم گیری می شود. این رخداد ها در مقایسه با auto pilot، به طرز قابل توجهی آهسته تر انجام می شوند و به انرژی بسیار بیشتری نسبت به عملکردهای اتوماتیک انسان نیاز دارند. تئوری فرایند دوگانه در روانشناسی تخمین می زند که این نوع از فعالیت های مغزی کاملا متفاوت پردازش می شوند و دو پروسه متفاوت برای این دو نوع از تفکر وجود دارد. یکی از آنها مخفی است. اتوماتیک و فرایندی ناخودآگاه است. و دیگری پروسه تفکر آگاهانه و خودآگاه است. تفکر ناخوداگاه در طول زمان شکل میگیرد و تغییر آنها بسیار سخت است. چرا که تغییر آن نیازمند توسعه و کار بر روی یک عادت جدید است که کار سهلی نیست. در مقابل، تفکر خودآگاه، می تواند توسط علت یابی های منطقی یا دانش، جایگزین شود و تغییر کند.هر دو این فرایند یا سیستم ها خوشبختانه در یک مغز وجود دارند، اما نحوه عملکرد آنها متفاوت است. تفکر ناخودآگاه را System 1 و خودآگاه را System 2 نیز می گویند:تفاوت های تفکر خودآگاه و ناخودآگاهاما همه اینها چه ارتباطی با DDD دارند؟ نکته مهم در اینجا، چگونگی تصمیم گیری توسط ماست. به طور علمی اثبات شده است که همه انسان ها دارای سوگیری شناختی هستند. بعنوان برنامه نویس، ما راههای خودمان را برای رفع مشکل های فنی داریم و آماده برای کد زدن در زمانی هستیم که چالش های مختلف در بیزینس یک پروژه برای ما بوجود می آید. اما از طرف دیگر، مشتریان ما نیز دارای سوگیری هستند. آنها احتمالا قبلا بدون نرم افزار ما نیز در حال کسب درآمد بوده اند یا ممکن است با استفاده از نرم افزارهای قدیمی 20 سال پیش نیز کار خود را پیش برده باشند. بنابراین ممکن است آنها فقط بدنبال یک روش مدرن یا ابری برای همان مساله باشند که قبلا حل کرده اند. نکته ای که قصد رسیدن به آن را دارم این است که ما باید تلاش کنیم سوگیری های ذهنی خود را تا حد ممکن کاهش دهیم و با ذهنی بازتر به آن چیزی که مشتری نیاز دارد توجه کنیم و در تله سوگیری های خودمان نیافتیم. همین، دلیلی است که گوگل کارگاهی با عنوان سوگیری ناخودآگاه برای کارکنان خود ایجاد می کند تا به تیم خود در آگاه شدن از سوگیری ها و کمک به رفع آن یاری برساند.مدل پیچیدگی Cynefin ما را مجاب می کند که حداقل پیچیدگی هایی که در فضای مساله (و بعضی اوقات در فضای راه حل) وجود دارد را دسته بندی کنیم. اما برای انتخاب دسته بندی مناسب، باید تصمیم گیری های زیادی انجام دهیم که معمولا از ذهن ناخودآگاه و بر اساس سوگیری های شخصی و تجارب گذشته خودمان انجام می شود، بجای اینکه توسط ذهن خودآگاه بوسیله تفکر و منطق شکل بگیرد. شاید همه ما کسانی را بشناسیم که حتی قبل از اینکه مشکل را کامل مطرح کنیم، با گفتن آره، این که انجامش راحته واکنش نشان می دهند.سوگیری های شناختی نقش اساسی اینجا ایفا می کند. برخی از آنها تاثیر عمیقی روی تصمیم گیری ما می گذارد و قطعا در نتیجه تفکر سیستم 1 است. در زیر برخی از سوگیری ها و سرنخ هایی وجود دارد که می تواند در تفکر شما در طراحی سیستم اثرگذار باشد:سوگیری حامی انتخاب: وقتی انتخابی انجام می دهید، حس مثبتی نسبت به آن انتخاب دارید، حتی اگر به شما اثبات شود که این انتخاب نقص های فراوانی دارد. معمولا این حالت در زمان ساخت اولین مدل ایجاد می شود و شخص سعی می کند به هر قیمتی به ادامه آن پافشاری کند، حتی با وجود اینکه ممکن است شواهدی مبنی بر عدم بهینگی این مدل وجود داشته باشد. این سوگیری مثلا زمانی که در حال انتخاب یک دیتابیس یا فریمورک هستید نیز می تواند رخ دهد.سوگیری تاییدی: تقریبا شبیه سوگیری قبلی است. این سوگیری باعث می شود فقط صحبت ها و مشورت هایی که همسو با انتخاب شما است را بشنوید و به مشورت های مخالف یا متضاد بی اعتنایی کنید. حتی اگر به خود شما هم اثبات شود که این مشورت ها صحیح هستند!اثر واگن-باند: وقتی اکثریت حاضر در اتاق روی چیزی توافق کنند، آن چیز شروع به منطقی بودن می کند! بدون درگیر کردن سیستم 2، نظر جمع؛ بدون حتی هیچ دلیل منطقی، اعتبار بیشتری دارد. به یاد داشته باشید که نظر جمع الزاما نظر صحیح نیست!اعتماد به سقف!: زیاد پیش می آید که افراد تمایل به مثبت نگری افراطی نسبت به قابلیت های خودشان داشته باشند. در این صورت ممکن است تصمیم گیری های نادرستی اتخاذ شود که تنها بدلیل نظر خودشان گرفته شده است. یک مثال بارز این سوگیری، فرایند تخمین است. افراد معمولا زمان کمتری را نسبت به واقعیت تا زمان بیشتر برای انجام یک کار تخمین می زنند.دسترسی اکتشافی: اطلاعاتی که ما داریم، الزاما تمام اطلاعات مورد نیاز برای حل یک مساله نیست. افراد تمایل دارند فقط بر اساس اطلاعاتی که دارند، تصمیم اتخاذ نمایند. بدون اینکه در صدد دریافت جزئیات بیشتر در مورد آن مساله باشند. معمولا این سوگیری باعث ساده سازی بیش از حد مساله در دامین شده و در نتیجه تخمین کمتری نسبت به پیچیدگی های ضروری واقعی اتخاذ می گردد. همچنین باعث می شود مثلا یک تکنولوژی برای مساله انتخاب شود، فقط به استناد اینکه همیشه این روش کار کرده است. در نهایت، با این که کار آسانی نیست، همیشه تلاش کنید تا از ذهن خودآگاه (سیستم 2) برای اتخاذ تصمیمات خود استفاده کنید.

آموزش Domain Driven Design. پیچیدگی ها

صادق شجری — Sat, 13 Jul 2024 14:19:30 +0330

در قسمت قبل، در مورد صنعت نرم افزار و مشکلاتی که از همان آغاز در آن وجود داشتند صحبت کردیم. با فضاهای مساله و راه حل آشنا شدیم و دریافتیم که چگونه ثابت ماندن در اولین راه حل و چکش کاری مداوم آن، باعث می شود تا بدنبال راه حل های دیگر نرویم، درحالیکه ممکن است راه حل های دیگر، بهترین گزینه برای ما باشد.حال قصد داریم در مورد پیچیدگی صحبت کنیم. مفهوم پیچیدگی در دنیای فیزیکی تفاوت چندانی با مفهوم آن در دنیای نرم افزار ندارد. بیشتر نرم افزار ها نوشته می شوند تا با مسائل و مشکلاتی که در دنیای واقعی وجود دارند، سروکار داشته باشند. این مسائل ممکن است در ظاهر ساده به نظر برسند اما در عین حال ذاتا دارای پیچیدگی های خاص خود هستند. بدون شک، پیچیدگی موجود در فضای مساله، در سیستمی که برای حل آن مساله نوشته خواهد شد، تاثیرگذار خواهد بود. تشخیص نوع پیچیدگی که در زمان ساخت نرم افزار با آن درگیر خواهیم بود، اهمیت بسزایی دارد.انواع پیچیدگیدر سال 1986، Fred Brooks مقاله ای نوشت که در آن پیچیدگی را به دو دسته بندی ضروری (essential) و تصادفی (accidental) تقسیم کرد. پیچیدگی ضروری از دامنه می آید. یعنی آنجا که خود مساله وجود دارد (problem space). این نوع پیچیدگی نمی تواند کاهش پیدا کند مگر با کسر بُعد خود مساله. در مقابل، پیچیدگی تصادفی از خود راه حل (solution space)، به راه حل افزوده میشود. این پیچیدگی می تواند شامل یک فریمورک، یک دیتابیس یا زیرساخت های دیگر باشد.سطح پیچیدگی تصادفی با بلوغ هرچه بیشتر صنعت نرم افزار، کاهش می یابد. زبان های برنامه نویسی سطح بالا و ابزارهای مختلفی که وجود دارد، باعث می شود برنامه نویسان وقت بیشتری را صرف فضای مساله (problem space) نمایند. اما همانطور که اشاره شد، اکنون پس از 30 سال، هنوز صنعت درگیر پیچیدگی های تصادفی است. ما ابزارهای قدرتمندی در اختیار داریم اما اکثر این ابزارها، خود نیازمند صرف زمان برای یادگیری هستند. نویسنده اشاره می کند که سالها پیش قطعه کدی به زبان Java Script نوشته بود. وقتی با Angular آشنا شد که چقدر بهتر آن کار را انجام می دهد، به سمت بازنویسی توسط Angular رفت. اما پس از مدتی دریافت که زمان بیشتری در نهایت صرف شد، چرا که یادگیری و چگونگی استفاده از Angular خود یک چالش بزرگ بود.بعنوان مثال دیگر، با وجود کانتینرها، میزبانی و استقرار اپلیکیشن ها ساده تر شد، اما در عین حال به یک Orchestration هم نیاز داریم و پس از مقداری یادگیری جدید، در میابیم که Kubernetes چه کمک بزرگی می تواند به ما کند. اینجاست که درگیر نوشتن YAML می شویم! تمام زمانی که در این مسیر صرف شد، می توانست درگیر نوشتن خود پروژه و حل مساله اصلی شود.غیر ممکن نیست که ما درگیر مسائلی می شویم که از خود فضای مساله نیز پیچیده تر می شوند. معمولا این اتفاق زمانی رخ می دهد که مسائل ما با راه حل های ما مخلوط شوند، یا ما نتوانسته باشیم به درک صحیحی از مساله دست یابیم.رشد پیچیدگی در گذر زمانهمانطور که در نمودار مشخص شده است، در گذر زمان، پیچیدگی های ضروری کاهش می یابند و پیچیدگی های تصادفی افزایش. ممکن است برای شما تعجب برانگیز باشد که با گذر زمان، پیچیدگی های ضروری تقریبا شیب صفر می گیرند (افزوده نمی شوند)، اما پیچیدگی های تصادفی حتی با شیب تندتر از قبل در حال افزوده شدن هستند. چطور این اتفاق رخ می دهد؟ قطعا ما زمان برای افزودن پیچیدگی تصادفی صرف نمی کنیم. زمانی که سیستم به مرور برجسته تر می شود، تلاش های فراوانی انجام می شود و کدهای پشتیبان افزایش می یابند، تا باعث شوند فقط سیستم بعنوان یک کل، کار کند. مثلا سیستم cache را پیاده سازی می کنیم، تلاش می کنیم عملکرد کوئری ها را بهبود دهیم، دیتابیس ها را تفکیک یا مرج می کنیم و ...در نهایت ممکن است ما تصمیم بگیریم پیچیدگی های ضروری را کاهش دهیم تا سیستم بدون مسائل جانبی فراوان، فقط درست کار کند.اما DDD به شما کمک می کند که بر روی مسائل پیچیده ای که در دامین وجود دارد (پیچیدگی های ضروری) تمرکز کنید. قطعا استفاده از ابزار های جدید فرانت اند یا استفاده از یک دیتابیس دایکیومنت کلود جذابیت دارد، اما بدون درک مشکلی که واقعا می خواهیم آن را حل کنیم، ممکن است این موارد فقط اتلاف وقت محسوب شود. DDD چندین تکنیک سودمند برای مدیریت پیچیدگی ها بوسیله تفکیک سیستم به بخش های کوچک تر ارائه می دهد که هر کدام از این بخش ها برای حل مجموعه ای از مشکلات مرتبط ایجاد می شوند. در بخش های آینده این تکنیک ها به تفصیل تشریح خواهند شد.با یک حساب سر انگشتی، اینطور می توان گفت:ضروریات (پیچیدگی های موجود در دامین) را در آغوش بگیرید و پیچیدگی های تصادفی را کاهش دهید. وظیفه شما، افزودن پیچیدگی های تصادفی نیست. در غیر این صورت احتمال افتادن در چاه over-engineering برای شما بالا خواهد رفت.

آموزش DDD. فضای مساله در برابر فضای راه حل

صادق شجری — Fri, 21 Jun 2024 20:05:56 +0330

پیشینه آغاز صنعت نرم افزار، به اوایل دهه 1960 میلادی باز میگردد و از آن زمان همیشه در حال پیشرفت و توسعه بوده است. اما از همان اولین سالها، پروژه هایی که دیر به نتیجه می رسیدند یا هزینه های هنگفتی برای تکمیل نیاز داشتند، بعلاوه پروژه های شکست خورده، تعداد بسیار بالایی را به خود اختصاص می دادند و این روند هم اکنون نیز ادامه دارد.بر اساس گزارشی که در سال 2015 منتشر شده است، پیش بینی شده است که بین سالهای 2011 تا 2015، فقط 22% از پروژه ها با موفقیت به سرانجام رسیده اند. 19% از پروژه ها کاملا شکست خورده اند و مابقی پروژه ها با چالش های مخصوص به خود در حال کشمکش و مبارزه هستند.در طول 4 دهه، بسیاری از روش های مدیریت پروژه های نرم افزاری ایجاد شدند و توسعه یافتند، اما یا بی اثر بودند یا تاثیر چندانی روی بهبود درصد پروژه های موفق نگذاشتند.یکی از فاکتورهای حیاتی موثر در موفقیت پروژه ها، شناخت مساله واقعی و تلاش به رفع آن است. منظور از مساله، آن مشکل یا موضوعی است که بخاطر آن، شما یا کارفرما به توسعه یک نرم افزار احساس نیاز کردید و فکر می کنید این نرم افزار قرار است مشکل معین و واضح پیش بینی شده را رفع کند. این مشکل (شناخت مساله)، دقیقا نقطه ای است که Domain Driven Design در صدد رفع آن است. این اصطلاح اولین بار در سال 2004 توسط Eric Evans در کتاب مشهور Domain-Driven Design: Tackling Complexity in the Heart of Software، به کار برده و تشریح شد. اصلی ترین عامل اقبال عمومی به این مفهوم این است که DDD تشریح می کند که افراد در صنعت IT چگونه می توانند به یک درک صحیح و جامع از نیازهای کاربران دست یابند تا بتواننند نرم افزارهایی توسعه دهند که مشکلات آنها را رفع کند و برای آنها تاثیر گذار باشد.شناخت مسالهما کد نمی نویسیم تا کد زده باشیم! ما پروژه ها را انجام می دهیم تا به دیگران کمک کنیم کارشان را سریع تر، بهتر و بهینه تر انجام دهند. بدون وجود مشکلی که باید حل شود، نوشتن پروژه کاری عبث است. از نگاه روانشانسی شناختی، مشکل عبارت است از فاصله وضعیت کنونی تا وضعیت دلخواه و ایده آل.فضای مساله و فضای راه حل (Problem Space و Solution Space)بشریت، مسائل و مشکلاتش را بوسلیه جستجو برای یک راه حل در فضای مساله برطرف می سازد. این فضا، بیانگر حالت های اولیه (initial state) و وضعیت ایده آل(desired state) است، همانطور که وضعیت های میانه ای نیز وجود دارد. این تئوری توسط Allen Newel و Herbert Simon مطرح شد. همچنین این فضا شامل قواعد و شاخصه هایی است که زمینه مساله را تعریف می سازد.در صنعت نرم افزار، افرادی که درگیر مساله هستند، معمولا مشتریان و کاربران هستند.برای هر مساله، راه حلی وجود دارد. اگر بدرستی در فضای مساله جستجو کنیم، متوجه قدمهای مورد نیاز برای گذار از حالت اولیه به حالت ایده آل خواهیم شد. این فضا را فضای راه حل می گویند.داستان رایجی که برای تعریف این دو فضا استفاده می شود، داستان نوشتن در فضاست. در دهه 1960، دانشمندان به مساله ای برخوردند که خودکارهای رایج در فضا به علت تفاوت های جاذبه، قابل استفاده نیستند. ناسا چندین میلیون دلار هزینه کرد تا خودکاری متناسب با این شرایط ابداع کند، اما شوروی برای رفع این مشکل، بجای خودکار، از مداد استفاده کرد و بدون صرف زمان و هزینه مشکل را رفع کرد!اصلا کمیاب و عجیب نیست که تفسیرهای ما از مشکلات موجود در دنیای واقعی اشتباه باشد. به گونه ای که پیچیدگی های غیر لازمی را برای رسیدن به راه حل می افزائیم و سپس مجبور می شویم مشکلاتی را رفع کنیم که اصلا وجود نداشتند!البته ناسا بعد از این ماجرا شروع به استفاده از مداد کرد اما بعد بخاطر مشکلاتی از قبیل تولید ریزگردها، شکستن نوک مدادها و احتمال آتش گرفتن مداد بخاطر جنس چوبی آن، استفاده از مداد را متوقف کرد. بعدها یک شرکت خصوصی به نام Fisher نوع خاصی از خودکار را برای استفاده در خلاء توسعه داد و ناسا پس از آزمایش آن، تصمیم به استفاده از آن گرفت. این خودکار سپس مورد توجه شوروی قرار گرفت و به مرور در سرتاسر جهان مشتریانی پیدا کرد. قیمت این خودکار برای همه یکسان و 2.39 دلار بود.در اینجا شما بُعد دیگری از مساله فضای مشکل/راه حل را می بینید. اگرچه در ظاهر، مساله ساده به نظر می رسید، محدودیت های جدیدی پدیدار شد که بعنوان نیازمندی های عملیاتی، باعث شد راه حل، پیچیده تر از چیزی که در ابتدا به نظر می رسید شود.پریدن به سمت راه حل بسیار آسان است. مخصوصا برای ما که تجربه فراوانی در حل مشکلات در کدها یا حرفه خود داریم. تفکر در مورد راه حل، مانع از تفکر مغز ما در مورد خود مشکل می شود. بجای تفکر در مورد مشکل، ما در راه حلی که در ابتدا به ذهنمان خطور کرده غرق می شویم که باعث ایجاد مراتب بیشتری از جزئیات می شود و در نهایت به این نتیجه می رسیم که راه حل ما بهترین راه حل ممکن برای حل آن مشکل معین است.پس جنبه دیگری که در جستجوی راه حل برای مساله بوجود می آید، خطر ثابت ماندن (قفلی زدن!) در اولین راه حلی است که به ذهنمان خطور کرده. این راه حل معمولا صرفا بدلیل تجارب شخصی ما در حل مشکلات قبلی توسط مغز ما انتخاب شده است، نه به این خاطر که بهترین راه حل ممکن است!پالایش در مقایسه با اکتشافرویکرد اکتشافی، شامل جستجو و انتخاب راه حل های مختلف، مستلزم کار فراوان و امتحان راههای مختلف است، بجای اینکه روی بهبود متوالی یک ایده خوب متمرکز شود (پالایش). اما راه حلی که توسط این اکتشاف بدست می آید، احتمال دقیق تر بودن و ارزشمندتر بودن بیشتری دارد.نیازمندی ها، چه مشکلی با ما دارند؟!معمولا توسعه دهندگان ارتباط کمی با کسی که بدنبال حل واقعی مشکلش هست دارند. معمولا افراد دیگری مانند تحلیل گرها، آنالیزر های کسب و کار یا مدیر پروژه ها با مشتریان صحبت می کنند و خروجی مکالماتشان را در قالب نیازمندی های فنی و عملیاتی در اختیار تیم توسعه دهنده قرار می دهند. این نیازمندی ها به اشکال گوناگونی در اختیار توسعه دهندگان قرار می گیرند. یا به صورت یک دایکیومنت بلند بالا به نام سند مشخصات مورد نیاز (requirements specifications) یا بصورت منعطف تر (agile) در قالب یوزر استوری ها.مثال زیر را در نظر بگیرید:هر روز، سیستم باید برای هر هتل، یک لیست از مهمان هایی که انتظار می رود در آن روز ورود و خروج کنند، تولید کند.همانطور که می بینید، این عبارت فقط راه حل را شرح می دهد. ما درکی از این نداریم که کاربر در حال انجام چه کاری است و چه مشکلی را سیستم ما باید رفع کند. نیازمندی های اضافی مورد نیاز نیز باید مشخص شده، سپس راه حل باید پالایش شود. اما شرحی از خود مساله هیچوقت در مشخصات مورد نیاز نیامده است.در مقابل، توسط یوزر استوری ها، بینش بیشتری در مورد آنچه کاربران نیاز دارند بدست می آوریم. بیایید یک یوزر استوری واقعی در زندگی را مرور کنیم:بعنوان یک مدیر انبارداری، میخواهم قادر باشم یک گزارش در سطح انبار دریافت کنم تا بتوانم محصولاتی را که موجودی آنها نزدیک به صفر هست را مجددا سفارش دهم.اکنون ما این بینش را داریم که کاربر چه گزارشی نیاز دارد. اما این یوزر استوری در واقع به توسعه دهنده دیکته می کند که باید چه کاری انجام دهد یا ندهد. پس این یوزر استوری نیز مستقیم به راه حل اشاره می کند. در حالیکه احتمالا مساله اصلی کاربر، نیاز به یک فرایند هوشمند تر برای جلوگیری از کاهش موجودی انبارها می باشد. یا شاید کاربر به دنبال یک سیستم پیشرفته پیش بینی خرید است که بتواند بدون ذخیره سازی اضافه، زمان سفارشات بعدی خود را بداند.اصلا به این فکر نکنید که صرف زمان برای درک نیازمندی های کاربر، کاری عبث و اتلاف وقت است. شناخت این نیازمندی ها که تقریبا همیشه بیانگر درکی درست از مشکل واقعی از زاویه دید کاربر است، امری حیاتی است. عدم درک مشکل واقعی کاربر، باعث صرف زمان و هزینه بیشتر و بیشتر و شاید ایجاد فیچرهایی با کیفیت بالا می شود، اما شاید در جهتی متفاوت از رفع مشکل واقعی کاربر!روش های agile و lean مشوق خوبی برای ارتباط مستقیم و بیشتر بین توسعه دهندگان و کاربران نهایی هستند. درک مشترک مسائل بین همه سهامداران، توسعه دهندگان و کاربران نهایی و تست کنندگان، یافتن راه حل ها به کمک یکدیگر، از بین بردن فرضیات غلط و ساخت پروتوتایپ هایی برای کاربران نهایی، همه این موارد می تواند منتج به دستیابی به یک تیم موفق و در نتیجه یک پروژه موفق می گردد. در بخش بعدی خواهیم دید که این مفاهیم ارتباط نزدیکی با DDD دارند!