پیشگفتار — Julie Lerman
طراحی دامنهمحور مجموعهای از شیوهها را برای رویکردی مشارکتی به ساخت نرمافزار از دید کسبوکار ـ یعنی دامنه و مسائلی که هدف حل آنهاست ـ ارائه میکند. این اصطلاح در سال ۲۰۰۳، همزمان با انتشار کتابی از Eric Evans که در جامعهٔ DDD با محبت «کتاب آبی» (The Blue Book) نامیده میشود، مطرح شد. عنوان آن کتاب Domain-Driven Design: Tackling Complexity in the Heart of Software است.
هرچند هدف طراحی دامنهمحور مقابله با پیچیدگی و فراهم کردن راهی برای رسیدن به وضوح است، ایدههای ارزشمند فراوانی در آن وجود دارد که حتی برای پروژههای نرمافزاری کمپیچیدهتر هم کاربرد دارند. DDD به ما یادآوری میکند که توسعهدهندگان نرمافزار تنها افراد دخیل در ساخت نرمافزار نیستند. متخصصان دامنه ـ کسانی که نرمافزار برای آنها ساخته میشود ـ درکی حیاتی از مسائل در حال حل دارند.
در سراسر مراحل ساخت، با متخصصان دامنه شراکت ایجاد میکنیم. ابتدا «طراحی راهبردی» (Strategic Design) را بهکار میبریم تا مسئلهٔ کسبوکار، یعنی دامنه، را بفهمیم و آن را به مسائل کوچکتر، حلشدنی و بههمپیوسته تقسیم کنیم. این شراکت همچنین ما را وادار میکند به زبان خود دامنه ارتباط برقرار کنیم، نه اینکه افراد سمت کسبوکار را مجبور کنیم زبان فنی نرمافزار را بیاموزند.
مرحلهٔ دوم یک پروژهٔ مبتنی بر DDD «طراحی تاکتیکی» (Tactical Design) است؛ جایی که یافتههای طراحی راهبردی را به معماری و پیادهسازی نرمافزار تبدیل میکنیم. در اینجا نیز DDD راهنمایی و الگوهایی برای سازماندهی دامنهها و جلوگیری از پیچیدگی بیشتر ارائه میکند. طراحی تاکتیکی شراکت با متخصصان دامنه را ادامه میدهد؛ بهگونهای که آنها حتی هنگام نگاه کردن به کدی که تیمهای نرمافزاری ساختهاند، زبان دامنهٔ خود را تشخیص میدهند.
در سالهای پس از انتشار «کتاب آبی»، نهتنها سازمانهای زیادی از این ایدهها بهره بردهاند، بلکه جامعهای از متخصصان باتجربهٔ DDD نیز شکل گرفته است. ماهیت مشارکتی DDD باعث شده این جامعه تجربهها و دیدگاههای خود را به اشتراک بگذارد و ابزارهایی بسازد که به تیمها برای پذیرش و بهرهگیری از این ایدهها کمک کند. Eric Evans در سخنرانی اصلی Explore DDD در سال ۲۰۱۹ جامعه را تشویق کرد که DDD را همچنان تکامل دهد؛ نه فقط شیوههای آن را، بلکه روشهای مؤثرتر برای انتقال ایدههایش را نیز.
و همین موضوع مرا به دلیل علاقهام به Learning Domain-Driven Design میرساند. من پیشتر از طریق سخنرانیهای کنفرانسی و نوشتههای دیگر Vlad طرفدار او بودم. او تجربهٔ سختبهدستآمدهٔ فراوانی بهعنوان متخصص DDD در پروژههای عمیقاً پیچیده دارد و این دانش را سخاوتمندانه به اشتراک گذاشته است. در این کتاب، «داستان» DDD ـ نه تاریخچهاش، بلکه مفاهیمش ـ را از زاویهای منحصربهفرد روایت میکند و دیدگاهی عالی برای یادگیری به دست میدهد.
کتاب برای تازهواردان نوشته شده، اما من با وجود سالها کار با DDD و نوشتن و سخن گفتن دربارهٔ آن، از دیدگاه Vlad چیزهای زیادی یاد گرفتم. حتی پیش از انتشار کتاب مشتاق بودم در دورهٔ DDD Fundamentals خود در Pluralsight به آن ارجاع دهم و بخشی از این دیدگاه را در گفتگوهایم با مشتریان بهکار گرفته بودم.
شروع کار با DDD میتواند گیجکننده باشد. همانطور که از DDD برای کاهش پیچیدگی پروژهها استفاده میکنیم، Vlad موضوع خود DDD را نیز به شکلی ارائه میکند که پیچیدگی آن را کاهش میدهد. او فقط اصول DDD را توضیح نمیدهد. بخشهای پایانی کتاب برخی شیوههای مهمی را که از دل DDD رشد کردهاند ـ مانند EventStorming ـ معرفی میکنند، مسئلهٔ تغییر تمرکز کسبوکار یا سازمان و اثر احتمالی آن بر نرمافزار را بررسی میکنند، و توضیح میدهند DDD چگونه با میکروسرویسها همراستا میشود و چگونه میتوان آن را با مجموعهای از الگوهای شناختهشدهٔ نرمافزار ترکیب کرد.
به باور من، Learning Domain-Driven Design مقدمهای عالی برای تازهواردان به DDD و مطالعهای بسیار ارزشمند برای متخصصان باتجربه نیز خواهد بود.
— Julie Lerman
مربی نرمافزار، نویسندهٔ O’Reilly و حامی دیرینهٔ DDD
مقدمهٔ نویسنده
روز شروع نخستین شغل واقعیام در مهندسی نرمافزار را بهوضوح به یاد دارم. هم سرخوش بودم و هم وحشتزده. پس از سالهای دبیرستان که برای کسبوکارهای محلی نرمافزار میساختم، مشتاق بودم یک «برنامهنویس واقعی» شوم و برای یکی از بزرگترین شرکتهای برونسپاری کشور کد بنویسم.
در روزهای اول، همکاران جدیدم راهوچاه را نشانم میدادند. بعد از راهاندازی ایمیل سازمانی و کار با سامانهٔ ثبت زمان، بالاخره به بخش جالب رسیدیم: سبک و استانداردهای کدنویسی شرکت. به من گفته شد: «اینجا همیشه کد خوبطراحیشده مینویسیم و از معماری لایهای استفاده میکنیم.» تعریف هر سه لایه ـ دسترسی به داده، منطق کسبوکار و ارائه ـ را مرور کردیم و سپس دربارهٔ فناوریها و چارچوبهای مناسب نیازهای هر لایه صحبت کردیم.
آن زمان، راهکار پذیرفتهشده برای ذخیرهٔ داده Microsoft SQL Server 2000 بود و در لایهٔ دسترسی به داده با ADO.NET یکپارچه میشد. لایهٔ ارائه هم برای برنامههای دسکتاپ WinForms و برای وب ASP.NET WebForms را بهکار میگرفت. زمان زیادی صرف این دو لایه کردیم، بنابراین وقتی لایهٔ منطق کسبوکار تقریباً هیچ توجهی نگرفت، سردرگم شدم:
«پس لایهٔ منطق کسبوکار چه؟»
«آن یکی ساده است. اینجا منطق کسبوکار را پیادهسازی میکنی.»
«اما منطق کسبوکار چیست؟»
«خب، منطق کسبوکار همان حلقهها و دستورهای if-else است که برای پیادهسازی نیازمندیها لازم داری.»
همان روز سفر من برای فهمیدن اینکه منطق کسبوکار دقیقاً چیست و چگونه باید در کدی با طراحی مناسب پیاده شود آغاز شد. بیش از سه سال طول کشید تا بالاخره پاسخ را پیدا کنم.
پاسخ در کتاب بنیادین Eric Evans، یعنی Domain-Driven Design: Tackling Complexity in the Heart of Software بود. معلوم شد اشتباه نمیکردم: منطق کسبوکار واقعاً مهم است؛ قلب نرمافزار است! با این حال، سه سال دیگر زمان برد تا خردی را که Eric به اشتراک گذاشته بود بفهمم. کتاب بسیار پیشرفته است و اینکه انگلیسی زبان سوم من بود هم کمکی نمیکرد.
در نهایت همهچیز سر جای خود قرار گرفت و با روششناسی طراحی دامنهمحور (DDD) کنار آمدم. اصول و الگوهای DDD، ظرافتهای مدلسازی و پیادهسازی منطق کسبوکار و شیوهٔ مقابله با پیچیدگی در قلب نرمافزاری که میساختم را آموختم. با وجود موانع، کاملاً ارزشش را داشت. ورود به DDD برای من تجربهای بود که مسیر حرفهایام را تغییر داد.
چرا این کتاب را نوشتم
در ۱۰ سال گذشته، طراحی دامنهمحور را در شرکتهای مختلف به همکارانم معرفی کردهام، کلاسهای حضوری برگزار کردهام و دورههای آنلاین تدریس کردهام. نگاه آموزشی نهتنها دانش خودم را عمیقتر کرد، بلکه کمک کرد شیوهٔ توضیح دادن اصول و الگوهای DDD را بهینه کنم.
همانطور که معمولاً رخ میدهد، آموزش حتی از یادگیری هم دشوارتر است. من از طرفداران بزرگ آثار و آموزههای Eliyahu M. Goldratt هستم. Eliyahu میگفت حتی پیچیدهترین سامانهها، اگر از زاویهٔ درست دیده شوند، ذاتاً سادهاند. در سالهای تدریس DDD بهدنبال مدلی از این روششناسی بودم که سادگی ذاتی طراحی دامنهمحور را آشکار کند.
این کتاب حاصل آن تلاشهاست. هدف آن دموکراتیک کردن طراحی دامنهمحور است؛ یعنی آسانتر کردن فهم آن و دسترسپذیرتر کردن استفاده از آن. باور دارم روششناسی DDD، بهویژه هنگام طراحی سامانههای نرمافزاری مدرن، ارزشی بسیار زیاد دارد. این کتاب ابزارهای کافی در اختیارتان میگذارد تا DDD را در کار روزمرهٔ خود بهکار بگیرید.
چه کسانی باید این کتاب را بخوانند
به باور من، شناخت اصول و الگوهای طراحی دامنهمحور برای مهندسان نرمافزار در همهٔ سطوح ـ junior، senior، staff و principal ـ مفید است. DDD فقط ابزارها و تکنیکهایی برای مدلسازی و پیادهسازی مؤثر نرمافزار ارائه نمیکند؛ بلکه جنبهای از مهندسی نرمافزار را که اغلب نادیده گرفته میشود روشن میکند: «زمینه» (Context).
وقتی مسئلهٔ کسبوکاری سامانه را میشناسید، در انتخاب راهکار مناسب بسیار مؤثرتر خواهید بود؛ راهکاری که نه کمتر از نیاز مهندسی شده باشد و نه بیش از حد، بلکه نیازها و اهداف کسبوکار را پاسخ دهد.
طراحی دامنهمحور برای معماران نرمافزار اهمیت بیشتری دارد و برای کسانی که میخواهند معمار نرمافزار شوند حتی مهمتر است. ابزارهای تصمیمگیری طراحی راهبردی آن کمک میکند یک سامانهٔ بزرگ را به مؤلفهها ـ سرویسها، میکروسرویسها یا زیرسامانهها ـ تجزیه کنید و نحوهٔ یکپارچه شدن این مؤلفهها برای تشکیل کل سامانه را طراحی کنید.
در نهایت، در این کتاب نهفقط دربارهٔ طراحی نرمافزار، بلکه دربارهٔ همتکامل دادن طراحی با تغییرات زمینهٔ کسبوکار صحبت خواهیم کرد. این جنبهٔ حیاتی مهندسی نرمافزار کمک میکند طراحی سامانه در گذر زمان «سرحال» بماند و به یک Big Ball of Mud تبدیل نشود.
راهنمای حرکت در کتاب
کتاب به چهار بخش تقسیم شده است: طراحی راهبردی، طراحی تاکتیکی، DDD در عمل، و رابطهٔ DDD با روششناسیها و الگوهای دیگر. در بخش اول، ابزارها و تکنیکهای تصمیمگیری طراحی در مقیاس بزرگ را بررسی میکنیم. در بخش دوم، تمرکز روی کد و روشهای مختلف پیادهسازی منطق کسبوکار است. بخش سوم تکنیکها و راهبردهای بهکارگیری DDD در پروژههای واقعی را بررسی میکند. بخش چهارم بحث طراحی دامنهمحور را در زمینهٔ روششناسیها و الگوهای دیگر ادامه میدهد.
خلاصهٔ فصلها:
- فصل ۱ زمینهٔ یک پروژهٔ مهندسی نرمافزار ـ دامنهٔ کسبوکار، اهداف آن و نحوهٔ پشتیبانی نرمافزار از آنها ـ را بنا میکند.
- فصل ۲ مفهوم «زبان فراگیر» (Ubiquitous Language)، شیوهٔ DDD برای ارتباط و اشتراک دانش مؤثر، را معرفی میکند.
- فصل ۳ نحوهٔ مقابله با پیچیدگی دامنههای کسبوکار و طراحی مؤلفههای معماری سطحبالای سامانه، یعنی Bounded Contextها، را بررسی میکند.
- فصل ۴ الگوهای مختلف سازماندهی ارتباط و یکپارچهسازی میان Bounded Contextها را بررسی میکند.
- فصل ۵ بحث الگوهای پیادهسازی منطق کسبوکار را با دو الگوی مناسب منطق ساده آغاز میکند.
- فصل ۶ از منطق ساده به منطق پیچیده میرود و الگوی Domain Model را برای مقابله با پیچیدگی معرفی میکند.
- فصل ۷ بُعد زمان را اضافه میکند و روش پیشرفتهتری برای مدلسازی و پیادهسازی منطق کسبوکار، یعنی Event-Sourced Domain Model، معرفی میکند.
- فصل ۸ سطح نگاه را بالاتر میبرد و سه الگوی معماری برای ساختاربندی مؤلفهها را شرح میدهد.
- فصل ۹ الگوهای لازم برای هماهنگسازی کار مؤلفههای سامانه را ارائه میکند.
- فصل ۱۰ الگوهای فصلهای قبل را به مجموعهای از قواعد سادهٔ راهنما تبدیل میکند که تصمیمگیری طراحی را روانتر میکنند.
- فصل ۱۱ طراحی نرمافزار را از منظر زمان و چگونگی تغییر و تکامل آن در طول عمر بررسی میکند.
- فصل ۱۲ EventStorming را معرفی میکند؛ کارگاهی کمفناوری برای اشتراک مؤثر دانش، ساخت درک مشترک و طراحی نرمافزار.
- فصل ۱۳ دشواریهای معرفی DDD به پروژههای Brownfield را بررسی میکند.
- فصل ۱۴ رابطهٔ سبک معماری میکروسرویس با DDD را توضیح میدهد: تفاوتها و نقاط مکمل.
- فصل ۱۵ الگوها و ابزارهای DDD را در زمینهٔ معماری رویدادمحور بررسی میکند.
- فصل ۱۶ بحث را از سامانههای عملیاتی به سامانههای مدیریت دادهٔ تحلیلی میبرد و تعامل DDD با معماری Data Mesh را بررسی میکند.
همهٔ این فصلها با تعدادی سؤال تمرینی پایان مییابند تا یادگیری تقویت شود. برخی پرسشها از شرکت خیالی «WolfDesk» برای نمایش جنبههای مختلف DDD استفاده میکنند. توضیح زیر را بخوانید و هنگام پاسخ به تمرینهای مرتبط به آن بازگردید.
دامنهٔ نمونه: WolfDesk
WolfDesk یک سامانهٔ مدیریت تیکتهای میز خدمت را بهصورت سرویس ارائه میکند. اگر شرکت نوپای شما نیاز دارد به مشتریانش پشتیبانی ارائه دهد، با راهکار WolfDesk میتوانید در زمان کوتاهی کار را آغاز کنید.
مدل پرداخت WolfDesk با رقبا متفاوت است. بهجای دریافت هزینه بهازای هر کاربر، به مستأجران (Tenants) اجازه میدهد هر تعداد کاربر که نیاز دارند ایجاد کنند و هزینه بر اساس تعداد تیکتهای پشتیبانی بازشده در هر دورهٔ صورتحساب محاسبه میشود. حداقل هزینهای وجود ندارد و برای آستانههای مشخصی از حجم تیکت ماهانه تخفیف خودکار اعمال میشود: ۱۰٪ برای بیش از ۵۰۰ تیکت، ۲۰٪ برای بیش از ۷۵۰ تیکت و ۳۰٪ برای بیش از ۱۰۰۰ تیکت در ماه.
برای جلوگیری از سوءاستفادهٔ مستأجران از مدل کسبوکار، الگوریتم چرخهٔ عمر تیکت WolfDesk تضمین میکند تیکتهای غیرفعال بهصورت خودکار بسته شوند؛ در نتیجه مشتریان تشویق میشوند برای نیازهای بعدی تیکت جدید باز کنند. افزون بر این، WolfDesk سامانهٔ تشخیص تقلبی دارد که پیامها را تحلیل میکند و مواردی را که موضوعات نامرتبط در یک تیکت واحد مطرح شدهاند تشخیص میدهد.
برای روانتر کردن کارهای پشتیبانی مستأجران، WolfDesk قابلیت «خلبان خودکار پشتیبانی» (Support Autopilot) را پیادهسازی کرده است. خلبان خودکار تیکتهای جدید را تحلیل میکند و میکوشد از تاریخچهٔ تیکتهای همان مستأجر راهحل سازگار پیدا کند. این قابلیت طول عمر تیکتها را باز هم کاهش میدهد و مشتریان را به باز کردن تیکت تازه برای سؤالهای بعدی تشویق میکند.
WolfDesk همهٔ استانداردها و تدابیر امنیتی لازم برای احراز هویت و مجوزدهی کاربران مستأجران را در خود دارد و همچنین به مستأجران اجازه میدهد ورود یکپارچه (Single Sign-On یا SSO) را با سامانههای مدیریت کاربر موجود خود پیکربندی کنند.
رابط مدیریتی به مستأجران اجازه میدهد مقادیر ممکن برای دستهبندی تیکتها و نیز فهرست محصولاتی را که آن مستأجر پشتیبانی میکند تنظیم کنند.
برای آنکه تیکتهای جدید فقط در ساعات کاری عاملان پشتیبانی به آنها مسیریابی شوند، WolfDesk امکان ثبت برنامهٔ شیفت هر عامل را فراهم میکند.
از آنجا که WolfDesk سرویس خود را بدون حداقل هزینه ارائه میکند، باید زیرساختش را طوری بهینه کند که هزینهٔ وارد کردن یک مستأجر جدید کمینه شود. برای این کار از رایانش بدونسرور (Serverless Computing) استفاده میکند تا منابع محاسباتی بر اساس عملیات انجامشده روی تیکتهای فعال بهصورت کشسان مقیاس پیدا کنند.
قراردادهای نگارشی استفادهشده در کتاب
کتاب از قراردادهای تایپوگرافی زیر استفاده میکند:
- Italic: نشاندهندهٔ اصطلاحات جدید، URLها، نشانیهای ایمیل، نام فایلها و پسوند فایلهاست.
- Constant width: برای فهرستهای کد و نیز اشارهٔ درونپاراگرافی به عناصر برنامه مانند نام متغیر یا تابع، پایگاه داده، نوع داده، متغیر محیطی، عبارتها و کلیدواژهها استفاده میشود.
استفاده از نمونهکدها
مطالب تکمیلی، شامل نمونهکدها، تمرینها و موارد مشابه، در وبسایت کتاب ارائه شدهاند: learning-ddd.com. تمام نمونهکدهای ارائهشده در کتاب با زبان C# پیادهسازی شدهاند. بهطور معمول نمونهکدهای فصلها گزیدههایی هستند که برای نمایش مفاهیم مورد بحث انتخاب شدهاند.
البته مفاهیم و تکنیکهای کتاب به زبان C# یا رویکرد برنامهنویسی شیءگرا محدود نیستند. همهٔ آنها برای زبانها و پارادایمهای برنامهنویسی دیگر نیز مرتبطاند. بنابراین میتوانید نمونههای کتاب را در زبان دلخواه خود پیادهسازی کنید و با نویسنده به اشتراک بگذارید؛ او از افزودن آنها به وبسایت کتاب استقبال میکند.
اگر دربارهٔ نمونهکدها پرسش فنی یا مشکلی دارید، میتوانید با bookquestions@oreilly.com تماس بگیرید.
هدف کتاب کمک به انجام کار شماست. در حالت کلی، اگر نمونهکدی همراه کتاب ارائه شده باشد، میتوانید آن را در برنامهها و مستندات خود استفاده کنید و مگر در حال بازتولید بخش قابلتوجهی از کد باشید نیازی به درخواست اجازه ندارید. برای مثال، نوشتن برنامهای که از چند قطعهٔ کد کتاب استفاده میکند به مجوز جداگانه نیاز ندارد. اما فروش یا توزیع نمونههای کتابهای O’Reilly نیازمند مجوز است. پاسخ دادن به یک سؤال با استناد به کتاب و نقل نمونهکد نیازمند مجوز نیست. وارد کردن مقدار قابلتوجهی از کد کتاب در مستندات محصول، نیاز به مجوز دارد.
ذکر منبع مورد قدردانی است، هرچند معمولاً الزامی نیست. یک نمونهٔ انتساب: «Learning Domain-Driven Design by Vlad Khononov (O’Reilly). Copyright 2022 Vladislav Khononov, 978-1-098-10013-1.» اگر استفاده از نمونهکدها خارج از Fair Use یا مجوز ارائهشده باشد، نشانی تماس ناشر: permissions@oreilly.com.
O’Reilly Online Learning
بیش از ۴۰ سال است که O’Reilly Media آموزش، دانش و بینش در حوزههای فناوری و کسبوکار ارائه میکند تا به موفقیت شرکتها کمک کند.
شبکهٔ منحصربهفرد متخصصان و نوآوران O’Reilly دانش و تجربهٔ خود را از طریق کتابها، مقالهها و سکوی یادگیری آنلاین این شرکت به اشتراک میگذارند. سکوی یادگیری آنلاین O’Reilly دسترسی درخواستی به دورههای آموزشی زنده، مسیرهای یادگیری عمیق، محیطهای تعاملی برنامهنویسی و مجموعهٔ گستردهای از متن و ویدئو از O’Reilly و بیش از ۲۰۰ ناشر دیگر میدهد. نشانی مرجع در نسخهٔ اصلی: oreilly.com.
نحوهٔ تماس
دیدگاهها و پرسشهای مربوط به کتاب را میتوان برای ناشر ارسال کرد:
O’Reilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
800-998-9938 (United States or Canada)
707-829-0515 (international or local)
707-829-0104 (fax)
صفحهٔ کتاب در نسخهٔ اصلی برای خطاها، مثالها و اطلاعات تکمیلی: oreil.ly/lddd. ایمیل پرسشهای فنی و نظرها: bookquestions@oreilly.com. منابع اجتماعی درجشده در کتاب: Facebook: facebook.com/oreilly، Twitter: twitter.com/oreillymedia، YouTube: youtube.com/oreillymedia.
سپاسگزاریها
این کتاب در ابتدا با عنوان «What Is Domain-Driven Design?» منتشر شده بود و در سال ۲۰۱۹ بهصورت یک گزارش انتشار یافت. بدون آن گزارش، Learning Domain-Driven Design شکل نمیگرفت؛ بنابراین نویسنده از Chris Guzikowski، Ryan Shaw و Alicia Young که شکلگیری آن گزارش را ممکن کردند تشکر میکند.
این کتاب بدون Melissa Duffield، مدیر محتوا و مسئول Diversity Talent در O’Reilly، نیز ممکن نبود؛ او از پروژه حمایت کرد و باعث شد به نتیجه برسد. نویسنده از Melissa برای همهٔ کمکهایش تشکر میکند.
Jill Leonard ویراستار توسعه، مدیر پروژه و مربی اصلی کتاب بود. نقش او در این اثر بسیار بزرگ بود. نویسنده از Jill بابت تلاش و کمک فراوانش ـ و بهویژه حفظ انگیزهٔ او حتی در زمانی که به تغییر نام و پنهان شدن در کشوری دیگر فکر میکرد ـ تشکر میکند.
سپاس فراوان از تیم تولید که کتاب را نهفقط قابلنوشتن بلکه خواندنی کرد: Kristen Brown، Audrey Doyle، Kate Dullea، Robert Romano و Katherine Tozer. نویسنده همچنین از تمام تیم O’Reilly برای کار عالیشان تشکر میکند و همکاری با آنها را تحقق یک رؤیا میداند.
از همهٔ افرادی که نویسنده با آنها مصاحبه یا مشورت کرده نیز تشکر شده است: Zsofia Herendi، Scott Hirleman، Trond Hjorteland، Mark Lisker، Chris Richardson، Vaughn Vernon و Ivan Zakrevsky؛ برای خردشان و حضورشان در زمان نیاز.
تشکر ویژه از تیم بازبینان که پیشنویسهای اولیه را خواندند و به شکلگیری نسخهٔ نهایی کمک کردند: Julie Lerman، Ruth Malan، Diana Montalion، Andrew Padilla، Rodion Promyshlennikov، Viktor Pshenitsyn، Alexei Torunov، Nick Tune، Vasiliy Vasilyuk و Rebecca Wirfs-Brock. حمایت، بازخورد و نقد آنها بسیار مؤثر بود.
همچنین از Kenny Baas-Schwegler، Alberto Brandolini، Eric Evans، Marco Heimeshoff، Paul Rayner، Mathias Verraes و باقی جامعهٔ شگفتانگیز طراحی دامنهمحور تشکر شده است. نویسنده آنها را معلمان و مربیان خود میداند و از اشتراک دانش در شبکههای اجتماعی، وبلاگها و کنفرانسها سپاسگزاری میکند.
بیشترین دین نویسنده به همسر عزیزش Vera است که همیشه از پروژههای عجیب او حمایت کرده و تلاش کرده عوامل حواسپرتی را از مسیر نوشتن دور کند. نویسنده قول میدهد بالاخره زیرزمین را مرتب کند و میگوید این اتفاق بهزودی خواهد افتاد.
در پایان، کتاب به Galina Ivanovna Tyumentseva تقدیم شده است؛ کسی که در این پروژه حمایت فراوانی از نویسنده کرد و متأسفانه در هنگام نگارش کتاب از دنیا رفت. نویسنده میگوید همیشه او را به یاد خواهند داشت.
#AdoptDontShop
درآمد (Introduction)
مهندسی نرمافزار دشوار است. برای موفقیت در آن باید پیوسته یاد بگیریم؛ چه امتحان کردن زبانهای جدید باشد، چه بررسی فناوریهای تازه یا همراه ماندن با چارچوبهای محبوب جدید. با این حال، یاد گرفتن یک چارچوب JavaScript تازه در هر هفته سختترین بخش کار ما نیست. فهمیدن دامنههای کسبوکار جدید میتواند بسیار چالشبرانگیزتر باشد.
در طول مسیر حرفهای، عجیب نیست که مجبور شویم برای طیف متنوعی از دامنههای کسبوکار نرمافزار بسازیم: سامانههای مالی، نرمافزار پزشکی، خردهفروشی آنلاین، بازاریابی و بسیاری حوزههای دیگر. از یک جهت، همین موضوع شغل ما را از بسیاری حرفههای دیگر متمایز میکند. افرادی که در حوزههای دیگر کار میکنند اغلب وقتی میفهمند مهندسی نرمافزار ـ بهویژه هنگام تغییر محل کار ـ تا چه اندازه یادگیری میطلبد، شگفتزده میشوند.
نفهمیدن دامنهٔ کسبوکار به پیادهسازی کمبهینهٔ نرمافزار کسبوکاری منجر میشود. متأسفانه این مسئله بسیار رایج است. طبق پژوهشها، حدود ۷۰٪ پروژههای نرمافزاری در زمان مقرر، در بودجهٔ مقرر یا مطابق نیازمندیهای مشتری تحویل نمیشوند. به بیان دیگر، اکثریت بزرگ پروژههای نرمافزاری شکست میخورند.
این مسئله آنقدر عمیق و فراگیر است که اصطلاحی برای آن داریم: «بحران نرمافزار» (Software Crisis). اصطلاح بحران نرمافزار در سال ۱۹۶۸ مطرح شد. طبیعی است تصور کنیم در بیش از ۵۰ سال پس از آن اوضاع بهتر شده باشد. در این سالها رویکردها، روششناسیها و رشتههای گوناگونی برای مؤثرتر کردن مهندسی نرمافزار معرفی شدند: Agile Manifesto، Extreme Programming، Test-Driven Development، زبانهای سطحبالا، DevOps و موارد دیگر. با این حال، وضعیت آنقدرها تغییر نکرده است. پروژهها هنوز هم زیاد شکست میخورند و بحران نرمافزار همچنان وجود دارد.
پژوهشهای زیادی برای بررسی علت شکستهای رایج پروژهها انجام شده است. پژوهشگران نتوانستهاند یک علت واحد را مشخص کنند، اما بیشتر یافتهها موضوع مشترکی دارند: ارتباطات (Communication).
مشکلات ارتباطی که پروژهها را از مسیر خارج میکنند میتوانند به شکلهای مختلف ظاهر شوند؛ برای نمونه، نیازمندیهای مبهم، اهداف نامشخص پروژه یا هماهنگی ناکارآمد تلاشها میان تیمها. با این حال، در طول سالها تلاش کردهایم ارتباطات درونتیمی و بینتیمی را با ایجاد فرصتها، فرایندها و رسانههای ارتباطی تازه بهبود دهیم. متأسفانه نرخ موفقیت پروژهها هنوز تغییر چشمگیری نکرده است.
طراحی دامنهمحور (DDD) پیشنهاد میکند ریشهٔ شکست پروژههای نرمافزاری از زاویهای متفاوت هدف قرار گیرد. ارتباط مؤثر موضوع مرکزی ابزارها و شیوههای DDD است که در این کتاب خواهید آموخت. DDD را میتوان به دو بخش تقسیم کرد: راهبردی و تاکتیکی.
ابزارهای راهبردی DDD برای تحلیل دامنهها و راهبرد کسبوکار و نیز ساخت یک درک مشترک از کسبوکار میان ذینفعان مختلف استفاده میشوند. همچنین از این دانش دامنه برای هدایت تصمیمهای طراحی سطحبالا استفاده خواهیم کرد: تجزیهٔ سامانهها به مؤلفهها و تعریف الگوهای یکپارچهسازی آنها.
ابزارهای تاکتیکی DDD جنبهٔ دیگری از مشکلات ارتباطی را هدف میگیرند. الگوهای تاکتیکی DDD به ما امکان میدهند کد را به شکلی بنویسیم که دامنهٔ کسبوکار را بازتاب دهد، اهداف آن را پاسخ دهد و به زبان کسبوکار سخن بگوید.
الگوها و شیوههای راهبردی و تاکتیکی DDD هر دو طراحی نرمافزار را با دامنهٔ کسبوکار آن همراستا میکنند. نام روش هم از همینجا میآید: طراحی نرمافزار که از دامنهٔ کسبوکار هدایت میشود.
طراحی دامنهمحور نمیتواند دانش کتابخانههای جدید JavaScript را مانند فیلم The Matrix مستقیماً در مغز شما نصب کند. اما با آسانتر کردن فرایند فهم دامنههای کسبوکار و هدایت تصمیمهای طراحی بر اساس راهبرد کسبوکار، شما را به مهندس نرمافزار مؤثرتری تبدیل میکند. همانطور که در فصلهای بعد میآموزید، هرچه ارتباط طراحی نرمافزار با راهبرد کسبوکار محکمتر باشد، نگهداری و تکامل سامانه برای پاسخ به نیازهای آیندهٔ کسبوکار آسانتر خواهد شد و در نهایت پروژههای نرمافزاری موفقتری به دست میآید.
سفر DDD را با بررسی الگوها و شیوههای طراحی راهبردی آغاز کنیم.