دامین دریون دیزاین، مفهوم دامنه ها
written on January 3, 2017در قسمت اول این نوشتار به برخی مفاهیم پایه ایی ددد اشاره کردم. در این قسمت بیشتر به بررسی دامنه ها و روش های داکیومنت کردن آنها می پردازیم.
این نوشته بخش دوم از سری مقالات کوتاهی است که سعی خواهد کرد درک و برداشت کنونی نویسنده از مفاهیم طراحی نرم افزار به روش دامین دریون دیزاین را به خواننده منتقل کند. با کمال میل آماده ی شنیدن نظرات شما در این زمینه هستم.
همانطور که قبلا اشاره شد دامنه ها و استقلال آنها از هم یکی از اصول مهم ددد می باشند. هر دامنه مجموعه ایی است از مفاهیم و تراکنش های میان آنها. به عنوان مثال در دامنه بخش تولید یک کمپانی، مفاهیمی وجود خواهند داشت مانند مدیر تولید، سرشیفت، کارگر، ساعت کاری، گزارش کاری ماهیانه و … همچنین در کنار این مفاهیم تراکنش هایی مانند “کارگر ساعت کار خود را ثبت می کند”، “سرکارگر گزارش کاری ماهیانه کارگر را تایید می کند” و “مدیر تولید کارگران برنامه ی کاری ماهیانه سرشیفت ها را تنظیم می کند”. جزییات این مفاهیم و تراکنش ها بستگی به واقعیتی دارد که نرم افزار قرار است بر پایه آن نوشته شود و باید با آنالیز دقیق شرایط و نیازهای کاربر نهایی به دست بیاید. هر تراکنش باید تا حد ممکن کوچک شود. یکی از مشکلات عمده این است که در خیلی از موارد کاربران به دلایل متفاوتی مفاهیم مربوط به چندین دامنه را با هم ترکیب می کنند. از مهمترین علل این مسئله این است که در دنیای واقعی یک کاربر بدون اینکه خود متوجه باشد نقش های متفاوت در دامنه های متفاوت را برعهده دارد. وظیفه مهم طراح نرم افزار در این موارد این است که در درجه اول دامنه های مختلف را از هم جدا کند و سپس به کاربر هم کمک کند تا نقش های خود در دامنه های مختلف را از هم تفکیک کند. به عنوان مثال شخصی که در بخش تولید نقش سرکارگر را بر عهده دارد ممکن است در تعیین حقوق یک کارگر هم نقش ایفا کند. در حالی که این تراکنش در حقیقت در دامنه ی حسابداری قرار دارد و ممکن است توسط سرکارگر یا هر نقش دیگر مثل مدیرتولید ایفا شود. بنابراین یک طراح خوب این تراکنش را در دامنه ی حسابداری و تحت عنوان یک نقش دیگر مدل خواهد کرد. نقشی که ممکن است توسط کاربری ایفا شود که در دامنه های دیگر هم نقش هایی را بر عهده دارد، مثل سرکارگر یا مدیرشیفت و یا توسط کسی ایفا شود که اصلا در بخش تولید فعالیت نمی کند.
ارتباط دامنه ها
در سیستمی که بیش از یک زبان فراگیر و در نتیجه بیش از یک دامنه وجود داشته باشد، لازم است در صورت نیاز، مفاهیم توسط مترجم هایی که در نقاط مرزی آنها را به یکدیگر تبدیل می کنند با هم ارتباط برقرار کنند. با هم به نموداری که با توجه به مثال آورده شده در بخش اول این نوشتار طراحی شده نگاه می کنیم:
در نمودار بالا سعی شده یکی از ساختارهای ممکن برای نرم افزاری مدل شود که تمام اجزای کمپانی نمونه ایی که قبلا از آن بحث شد را به نمایش می گذارد. در اینجا چهار دامنه درنظر گرفته شده که هرکدام مفاهیم خاص خود را دارد. مفاهیمی که در این مورد خاص همه به هم مرتبط می باشند. در این نمودار می توان دید که چطور مفاهیم دامنه های مختلف توسط مترجم ها به یکدیگر تبدیل می شوند. اینکه آیا تمام این مترجم ها لازم هستند یا اینکه منبع اولیه مفهوم دقیقا در کدام دامنه قرار دارد و اساسا اینکه آیا یک منبع واحد وجود دارد که باقی دامنه ها از آن استفاده می کنند یا نه، همگی بستگی به زبان فراگیر دامنه ها و ارتباط آنها به هم دارد. اما نکته ی بسیار مهمی که باید از این نمودار به خاطر سپرد این است که هر دامنه به صورت مجزا قابلیت عملکرد کامل دارد و در صورت نیاز این امکان وجود دارد که با تعویض زیرساخت یک دامنه و حداکثر با بازنویسی مترجم مربوطه کل سیستم همچنان قابل استفاده باقی می ماند.
اینکه مترجم ها چگونه اطلاعات را به دست می آروند و چگونه در اختیار دامنه ی دیگر قرار می دهند بستگی به ساختار دو دامنه ی مرتبط دارد. فرض کنیم در نمودار بالا بخش آی تی منبع اصلی اطلاعات حقوق بگیران در بخش حسابداری باشد و نرم افزار پیاده شده در بخش آی تی یک اینترفیس (API) وب مثلا بر پایه REST را در دسترس قرار می دهد. همچنین در ساده ترین حالت مترجم از هیچگونه کش (Cache) محلی استفاده نمی کند. در این حالت مترجم بین بخش حسابداری هر بار که نیاز به بدست آوردن اطلاعات مربوط به یک حقوق بگیر را دارد، یک درخواست به اینترفیس بخش آی تی خواهد فرستاد. روش های دیگری نیز می تواند برای پیاده سازی مترجم ها استفاده شوند، به عنوان مثال استفاده از رویداد ها (Events) یا حتی ترکیبی از رویدادها و اینترفیس. در بهترین حالت این مترجم ها به صورت یکطرفه و تنها خواندنی پیاده سازی میشوند. یعنی در این مثال، بخش حسابداری اطلاعات را از بخش آی تی فقط می خواند. در حالی که در خیلی از موارد هر دامنه نیاز به ذخیره ی اطلاعاتی اضافه بر آنچه که از بخش های دیگر بدست می آورد هم دارد. در این موارد دامنه وابسته، در اینجا بخش حسابداری، مدلی محلی دارد که اطلاعات مورد نیاز خود را ذخیره می کند. بخشی از اطلاعات که از خارج تهیه می شوند (معمولا شامل یک آیدنتیفایر و برخی اطلاعات پایه ایی) به صورت فقط خواندنی و تنها توسط مترجم تکمیل و مابقی اطلاعات به صورت قابل تغییر در سطح دامنه مدل میشوند. درک این مسئله احتمالا بعدا با کمک کمی کد قابل درک تر خواهد شد.
کشف و ضبط نیازهای دامنه
درک مفهوم دامنه ها، لزوم استقلال آنها از هم و روش ارتباط آنها با هم برای اعمال موفق ددد بسیار مهم است. توانایی یک طراح در اعمال مناسب این اصل به فاکتورهای متفاوتی مثل میزان تجربه، زمان و منابع اختصاص یافته به طراحی و غیره وابسته است. اما مهمترین عامل موفقیت، میزان ارتباط طراح یا طراحان با متخصصان دامنه می باشد. متخصصان دامنه کسانی هستند که از تجربه و دانش کافی در دامنه ی مدنظر برخوردار هستند بدون اینکه لزوما دارای دانش مرتبط به نرم افزار باشند. کسانی مثل حسابداران، سرشیفت ها، تکنیسین بخش آی تی، و یا حتی کارگر ساده ی بخش تولید نمونه هایی از متخصصان دامنه می باشند. بنابراین وظیفه ی طراح نرم افزار قبل از انجام هر کاری برقراری ارتباط مناسب با این افراد و جذب و ضبط دانش آنها برای استخراج مفاهیم و تراکنش ها می باشد. در بسیاری موارد برای هر دامنه تیمی تشکیل می شود شامل طراحان نرم افزار و متخصصان دامنه که به صورت مداوم و در تمام طول عمر طراحی و پیاده سازی نرم افزار با هم در ارتباط قرار دارند. در بهترین حالت این تیم براساس یک پروسه اجایل (Agile) ابتدا بدیهی ترین مفاهیم و تراکنش ها را کشف و ضبط و حتی پیاده سازی نموده و سپس به تدریج برجزییات آن می افزاید.
یکی از مواردی که طراح نرم افزار در این فاز باید مورد توجه قرار دهد این است که مفاهیم و تراکنش های ضبط شده نباید به هیچ عنوان تحت تاثیر مسایل نامرتبطی مثل جزییات تکنیکی، روش یا زبان برنامه نویسی، نوع و ساختار ذخیره سازی اطلاعات و … قرار بگیرد. تمام اینها مشکلات و جزییاتی هستند که چیزی به ارزش واقعی نرم افزار اضافه نمی کنند.
یکی از روشهای موفق در ضبط نیازهای یک دامنه تشکیل حداقل یک پرسونا (Persona) برای هر نقش و تشریح جزییات آن نقش می باشد. یک پرسونا تلاش می کند تا علایق، نیازها و دلایل یک شخص در نقش مورد نظر را تشریح کند که مرتبط به دامنه ی مربوطه می باشد. یک پرسونا ممکن است نقش های متفاوت در دامنه های متفاوت را هم تشریح کنند. نام، سن، دلایل استفاده از سیستم، کلاینت و ابزارهای مورد استفاده (موبایل، رایانه و …) از جمله مواردی هستند که در کنار نقش یک فرد در پرسونا تشریح می شوند.
برای ضبط تراکنش ها یوزر استوری ها (User Story) فرمت مناسبی هستند. یوزراستوری در قالب جملاتی کوتاه اما واضح و بدون ابهام تراکنش ها و نقش های دخیل در آنها را تشریح می کنند. به عنوان مثال جمله ی “سرکارگر در انتهای هر ماه ساعات کاری کارگرهای زیر دست خود را تایید می کند” می تواند یک نمونه از یوزراستوری باشد.
در قسمت بعدی نوشتار کمی از مباحث تئوری فاصله گرفته و جزییات بیشتری از مراحل پیاده سازی یک نرم افزار طراحی شده به روش ددد را مورد بررسی قرار خواهیم داد. همچنین نمونه های کدی ارائه می شوند که به درک مطلب کمک خواهد کرد.