انجمن برنامه نویسان البرز

تبلیغات

پیاده سازی User Story ها بر روی دامین


Domain driven design همانطور که از اسمش مشخص است، طراحی با تکیه بر روی دامین است. اما این جمله یعنی چه؟ اصلا دامین چیست؟

بیایید اینطور به داستان نگاه کنیم که دامین، در واقع مغز یک نرم افزار است. تمام روابط و فرآیندهای یک نرم افزار در دامین انجام میشود. به همین دلیل است که در Domain driven design به جای اینکه ابتدا از دیتابیس یا UI شروع کنیم، مغز نرم افزار را تحلیل میکنیم و میسازیم.

متاسفانه در طول سال ها، ما عادت کرده ایم که ابتدا فرآیندها را در دیتابیس بسازیم. برای مثال، هر وقت خواسته ایم یک نرم افزار آموزشگاهی بسازیم، با ساختن جدول های Student,Teacher,Lesson و غیره شروع کرده ایم. اصطلاحا یک رویکرد Database First یا Database Driven را پیش گرفته ایم.

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

یک مثال بهتر و کمی پیچیده تر : یک ماشین خودپرداز -ATM- را در نظر بگیرید. به جای اینکه به سراغ دیتابیس بروم و جداول Account,Customer,Transaction و … را بسازم، به سراغ فرآیندها میروم و فرآیند برداشت پول از ATM را مدل میکنم. به یک نکته بسیار مهم توجه کنید. در صورتی که برای پروسه برداشت پول از خودپرداز، بخواهم از روش Database Driven استفاده کنم، حل مسئله بسیار پیچیده خواهد بود. اما وقتی فرآیند را مدل میکنم، حل صورت مسئله ساده تر خواهد بود. به علاوه اینکه، فرآیند به من کمک میکند تا موجودیت ها را هم شناسایی کنم.

به سراغ مثال برویم: دریافت پول از خودپرداز. مشتری به سراغ دستگاه میرود. کارت را در آن میگذارد. کارت چک میشود. رمز خواسته میشود. رمز چک میشود و و و… مشاهده کردید، فرآیند ها خود به خود، نام ها و موجودیت های درگیر را به من معرفی میکنند. نکته دیگر اینکه فرآیندهای پیچیده، به طور خود به خود به من Hint میدهند که چه فرآیندهای کوچکتری را نیاز دارم.

این از ماجرای تفکر Domain Driven. در قدم بعدی به سراغ Scrum میرویم. در Scrum مفهومی به نام User Story وجود دارد. User Story همانطور که از اسمش پیداست، داستان انجام یک فرآیند است. فکر کنم کلید مطلب را گرفتید. User Story ها هم در واقع فرآیندها را مدل میکنند!!! ساختار یک User Story را در ذهنتان مجسم کنید:

As a ROLE, I want a FEATURE, So that I can DO SOMETHING

Given When CONDITION Then DO SOMETHING

حالا مثال خودپرداز را به یک User Story تبدیل میکنم:

به عنوان یک مشتری میخواهم از دستگاه خودپرداز پول برداشت کنم تا …

با در نظر داشتن این نکته که وقتی رمزم را ندانم، دستگاه به من پولی نمیدهد.

وقتی حسابی نداشته باشم، دستگاه به من پولی نمیدهد.

وقتی موجودی نداشته باشم، دستگاه به من پولی نمیدهد.

و و و…

 

حتما شما هم مثل من، فرآیندهای Domain را به خوبی در بالا میبینید. فرآیندهایی مثل : CheckPassword – CheckAccount – CheckCredite و و و که همگی به ترتیب در بدنه فرآیند GetCash استفاده میشوند.

به علاوه، نام هایی که در User Story استفاده کرده ایم، میتوانند کلاس ها و جداول ما را بسازند. نام هایی مثل: Customer – Account – Card – CashMachine

همانطور که میبینید، User Story ها هم یک فرآیند کاملا Domain Driven دارند. چه چیزی بهتر از این؟ اما صبر کنید، چیزهایی بهتر از این هم هست!!!

حالا بیایید تفکر TDD را هم داخل بازی بیاوریم!

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

اینجاست که TDD یا Test Driven Development کمک بسیار بزرگی به ما میکند. ما فرآیندها را به صورت Test First پیاده سازی مکنیم و به مرور که تست های بیشتری اضافه میکنیم، مغز نرم افزار – Domain – را هوشمندتر میکنیم. پس در قدم اول، Unit Testing برای UI و Data Layer را دور بریزید. این مغز نرم افزار ما است که نیاز به تست دارد. مطمئن باشید مایکروسافت، SQL Server را به اندازه کافی تست کرده است!!! شما نیازی به صرف کردن اینهمه Effort برای تست آن ندارید!!!

تفکر TDD به طور خود به خود، منجر به به وجود آمدن  Separation  of concerns در پیاده سازی فرآیندها میشود. هرچه فرآیندهای شما بیشتر Loosely Coupled باشند، سیستم شما محکم تر، قابل گسترش تر و استانداردتر شکل میگیرد.

 

مطمئنا پیاده سازی تفکر مبتنی بر دامین، در ایتدا کمی سخت است اما با ادامه این روش، به برتری های آن پی خواهید برد.

 

نویسنده : علیرضا صبوئی

راهنما : مهدی مدنی




کلمات کلیدی :

نظر بدهید

یک دیدگاه برای “پیاده سازی User Story ها بر روی دامین

  • حسین گفته
    10 آوریل 18

    سلام بسیار مفید بود مهندس
    منتظر مقلات بعدی شما هستیم.