تاملات گاه گاه یک توسعه دهنده نرم افزار

۲ مطلب در خرداد ۱۳۹۹ ثبت شده است

مجمع الجزایر تحلیل، توسعه، تست!

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

 

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

 

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

 

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

 

اگر هوای یک جزیره طوفانی شود از آسمان سیل ببارد و به شرایط طاقت‌فرسایی گرفتار شوند، کسی از جزایر بغلی، محلی به آنها نخواهد گذاشت و اینطور نیست که به قول سعدی «دگر عضوها را نماند قرار»!

 

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

 

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

 

اما چطور می‌توان محصول مشترکی ساخت وقتی که ذهنمان درگیر جنگ سرد بین جزایر است و به این فکر می‌کنیم که پرچم جزیره خودمان را بالا نگه داریم؟

 

آیا بهتر نیست همه ما خودمان را ساکن یک جزیره بدانیم و به فکر بالا نگه داشتن یک پرچم باشیم؟ پرچم تیم!

 

- روح‌الله دلپاک

 

۱ نظر موافقین ۰ مخالفین ۰
روح الله دلپاک

آیا «طراحی دامنه محور» ترجمه مناسبی برای Domain-Driven Design است؟

جستجوی عبارت «طراحی دامنه محور» در گوگل، بیش از ۲۰۰۰ نتیجه در بر دارد که می‌تواند نشانه‌ای از این باشد که عبارت «طراحی دامنه محور» به ترجمه‌ای متداول برای عبارت Domain-Driven Design تبدیل شده است. اما آیا چنین ترجمه‌ای، می‌تواند ایده اصلیِ رویکرد Domain-Driven Design را به مخاطب فارسی زبان بفهماند؟

 

هدف از این نوشته پیشنهاد یک ترجمه بهتر نیست (هر چند که از تلاش برای ارایه یک ترجمه بهتر استقبال می‌کنم) و صرفا به بررسی مناسب بودن عبارت «طراحی دامنه محور» برای ترجمه Domain-Driven Design بسنده می‌کنم.

 

از جمله موضوعاتی که در رویکرد DDD مورد تاکید فراوان قرار گرفته موضوع زبان فراگیر (Ubiquitous Language) است. منظور از زبان فراگیر، زبانی است که در هر نوع فعالیت مرتبط با توسعه محصول اعم از تحلیل، طراحی، پیاده‌سازی، تست و حتی مکاتبات رسمی و غیر رسمی مورد استفاده قرار می‌گیرد.

 

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

 

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

 

یافته‌های جدید ما از فضای مساله، مانند نیروی پنهانی هستند که به مدل وارد می‌شوند و مدل را بالغ‌تر می‌کنند و آن را به مدل مناسبتری برای حل مساله بدل می‌کنند.

اما منشا نیرویی که به کامل‌تر شدن مدل ما می‌انجامد چیست؟ منشاء این نیرو، حوزه مسایل کسب و کار یا به عبارت دیگر، همان Domain است. می‌توان گفت آنچه که طراحی ما را حالت می‌دهد (مانند خمیر بازی) و خوش فرم‌تر می‌کند، یافته‌های جدید و درک جدید ما از Domain است.

 

عبارت Domain-Driven Design هم بر همین موضوع دلالت دارد. سبکی از طراحی که کاملا تحت اثر نیرویی است که از Domain به آن وارد می‌شود و آن را وَرز می‌دهد. اگر در دامین مفهومی نو پدیدار شود یا مفهومی بسط پیدا کند و شفاف‌ شود، لاجرم باید آن تغییرات را در مدل منعکس کنیم.

 

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

 

اگر با این تعبیر از رویکرد #DDD موافق باشید، به نظر می‌رسد که عبارت «طراحی دامنه محور» ترجمه وفاداری به رویکرد DDD نیست. به این دلیل که اشاره‌ واضحی به این نکته‌ی مهم ندارد که طراحی «تحت تاثیر» نیرویی است که به دلیل تغییر و تحولات دامین به آن وارد می‌شود و آن را سر و شکل می‌دهد.

 

شاید مهمترین ضعف این ترجمه، انتخاب واژه «محور» به جای Driven- باشد که خب انتخاب دقیقی نیست. با رجوع به واژه‌نامه کمبریج می‌بینیم که در توضیح معنای -Driven (در شکل پسوندی)‌ گفته شده:

• Caused or influenced by something or someone.

- آنچه که تحت تاثیر چیزی یا کسی بوجود می‌آید و یا اتفاق می‌افتد.

 

لذا پسوند Driven- معنای «محور» یا «مرکز» ندارد و عبارت «طراحی دامنه محور» در ترجمه تحت الفظی نیز با اشکال همراه است.

 

جمع‌بندی:


عبارت «طراحی دامنه محور» به دو دلیل ترجمه مناسبی برای Domain-Driven Design نیست:

۱- ایده اصلی این رویکرد را به مخاطب منتقل نمی‌کند.

۲- در ترجمه تحت الفظی، «محور» ترجمه صحیحی از «-Driven» نیست.

 

۰ نظر موافقین ۰ مخالفین ۰
روح الله دلپاک