دامین دریون دیزاین، طراحی مشتق شده از واقعیت

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

«دامین دریون دیزاین» یا Domain Driven Design جزو اصطلاحاتی است که من معادل فارسی برای آن پیدا نکردم. به همین دلیل ترجمه ای تحت اللفظی از این اصطلاح صرفا برای درک مفهوم استفاده شده. تاکید همیشگی من بر ترجمه نکردن نامهاست. این حق باید برای ذهن های بزرگ ایجاد کننده ی مفاهیم بنیادی محفوظ بماند که نام پیده ی ایجاد شده را خود تعیین کنند.

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

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

آشنایی با اساس ددد

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

برای ممکن کردن این اهداف و برای نزدیک شدن به وضعیت ایده آل، ددد از ایده ها و روش هایی کمک می گیرد که هر کدام به تنهایی هم قابل استفاده هستند اما تنها در کنار هم و به صورت یک کل به اهداف ددد نزدیک می شوند. به کارگیری برخی از این روش ها اختیاری و وابسته به شرایط و به کارگیری برخی دیگر جزء جدایی ناپذیر ددد هستند. یکی از مهمترین این روش ها معماری لایه ایی است. در این معماری یک هسته ی مرکزی دربرگیرنده ی مهم ترین اجزا و عملکردهای نرم افزار خواهد بود و لایه های بعدی تنها به منظور مجزا و بی نیاز کردن این هسته ی مرکزی از تاثیر لایه های خارجی، انواع فریم ورک ها، دیگر ابزارهای برنامه نویسی و یا حتی دامنه های مفهومی دیگر که با اصل عملکرد نرم افزار به صورت مستقیم سر و کار ندارند، ایجاد و به کار گرفته می شوند. یکی دیگر از مفاهیم بسیار پرکاربرد در ددد، معکوس کردن وابستگی یا Dependency Inversion می باشد. تکنیکی که سعی در عدم وابسته کردن عملکرد نرم افزار به سیستم های جانبی مثل نوع دیتابیس، روش ذخیره سازی اطلاعات، وجود یا عدم وجود مدیریت تراکنش و موارد دیگر شبیه به آنها دارد. معکوس کردن وابستگی این امکان را ایجاد می کند که نرم افزار (یا حداقل هسته ی مرکزی آن) مستقل از این جزییات طراحی و پیاده سازی شود. خیلی از این جزییات تکنیکی برای بسیاری از برنامه نویس های با تجربه مسایل بسیار پر اهمیتی به حساب می آیند که از لحظه ی اول برنامه ریزی برای یک سیستم جدید در تصمیمگیری ها تاثیرگذار می شوند، اما در حقیقت نقشی در عملکرد واقعی نرم افزار ندارد یا در حقیقت نباید داشته باشند. در بخش های آینده این نوشتار با تکنیک های نامبرده و دیگر تکنیک های کوچک و بزرگ آشنا خواهید شد که شما را به عنوان یک طراح نرم افزار در مستقل کردن مهمترین جز یک سیستم نرم افزاری (یعنی عملکرد آن) از این جزییات فنی کمک خواهند کرد. اما قبل از پرداختن به این جزییات، به بنیادی ترین مفهوم ددد می پردازیم.

زبان فراگیر یا Ubiquitous Language

Ubiquitous Language هم یکی دیگر از مفاهیمی است که من معادل فارسی برای آن پیدا نکردم. لذا اینجا ترجمه ی تحت اللفظی آن را مورد استفاده می دهم.

اریک اوانس (Eric Evans) نویسنده ی کتاب Domain-Driven Design: Tackling Complexity in the Heart of Software که توسط بسیاری از طرفداران مفهوم ددد به عنوان کتاب مقدس این حوزه شناخته می شود، بیشترین تاکید را در تمام پروسه ی طراحی یک نرم افزار به شناخت زبان فراگیر مورد استفاده ی کاربران نهایی نرم افزار میکند. مفهوم زبان فراگیر به اصطلاحات، مفاهیم و حتی روندها و پروسه هایی اشاره می کند که کاربران نهایی یک سیستم نرم افزاری در روندهای روزمره ی خود از آنها استفاده می کنند. زبان فراگیر هر مجموعه و گروه از کاربران متفاوت از مجموعه و گروههای دیگر خواهد بود.

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

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

بزرگترین ایده پردازان و دست اندرکاران ایدئولوژیک حوزه ی ددد (مانند مارتین فولر Martin Fowler و واان ورنون Vaughn Vernon) متقدند در هر سیستم نرم افزاری بیش از یک زبان فراگیر دخالت خواهد داشت و چنانچه در یک سیستم نرم افزاری تنها و تنها یک زبان فراگیر شناسایی شود به احتمال زیاد طراح نرم افزار دچار اشتباهات بزرگی شده است. وظیفه طراح نرم افزار این است که زبانهای فراگیر دخیل در سیستمی که طراحی آن بر عهده اش گذاشته شده را شناسایی و برای هر کدام از آنها یک دامنه تعریف و در محدوده ی آن دامنه فقط و فقط با توجه به زبان فراگیر آن دامنه به مدلسازی نرم افزار اقدام کند.

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

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