بسیاری از عوامل باعث پیچیدگی توسعه نرم افزار می شوند. اما هسته اصلی این پیچیدگی، ذات درهم تنیده دامنه مسئله است.اگر قصد دارید تا اتوماسیونی را به فعالیت های پیچیده انسانی اضافه کنید، نرم افزار شما نمی تواند از این پیچیدگی طفره برود - تنها کاری که می تواند انجام دهید کنترل آن است.
کلید کنترل پیچیدگی، یک مدل دامنه خوب است، مدلی که فراتر از دید سطحی از یک دامنه عمل می کند و با معرفی یک ساختار زیربنایی که اهرم مورد نیاز را به توسعه دهندگان نرم افزار می دهد. یک مدل دامنه خوب می تواند بسیار با ارزش باشد، اما ساختن آن کار ساده ای نیست. افراد کمی می توانند آن را به خوبی ایجاد کنند و آموزش آن بسیار سخت است.
اریک ایوانز یکی از معدود کسانی است که می تواند مدل های دامنه را به خوبی ایجاد کند. من این مورد رو زمان همکاری با او کشف کردم - یکی از آن لحظات فوق العاده که شما همکاری را پیدا می کنید که از شما حرفه ای تر است. همکاری ما کوتاه اما بسیار لذت بخش بود.
این کتاب به گونه ای تکامل یافته است که جاه طلبی بزرگی را برآورده می کند: توصیف و ایجاد واژگانی در مورد هنر مدل سازی دامنه. برای ارائه یک چارچوب مرجع که از طریق آن بتوانیم این فعالیت را توضیح دهیم و همچنین این مهارت را که به سختی آموخته می شود ، آموزش دهیم. این کتاب با شکل گیریش ایده های جدید زیادی به من داده است و اگر حتی افراد باتجربه در مدل سازی مفهومی ، انبوهی از ایده های جدید را از خواندن این کتاب دریافت نکنند، شگفت زده خواهم شد. همچنین بسیاری از چیزهایی را که در طول سال ها آموخته ایم تثبیت می کند. اول، در مدل سازی دامنه، نباید مفاهیم را از پیاده سازی جدا کنید.
دوم شما نمی توانید یک مدل مفهومی مفید بدون در نظر گرفتن مسائل پیاده سازی بسازید. اما دلیل اصلی اینکه چرا مفاهیم و پیاده سازی به هم تعلق دارند این است که با ارزش ترین مدل های دامنه دارای یک زبان فراگیر هستند که متخصصان دامنه و متخصصان فنی را به هم پیوند می دهد.
درس دیگری که از این کتاب خواهید گرفت این است که مدل های دامنه ابتدا مدل سازی و سپس اجرا نمی شوند. من رویکرد مرحله‌ای «اول طراحی، سپس ساخت» را رد کرده‌ام. اما تجربه اریک این است که مدل‌های دامنه واقعاً قدرتمند با گذشت زمان تکامل می‌یابند، و حتی با تجربه‌ترین مدل‌سازان متوجه می‌شوند که بهترین ایده‌های خود را پس از انتشار اولیه یک سیستم به دست می‌آورند.
فکر می کنم و امیدوارم که این کتاب ، کتابی تأثیرگذار باشد. کتابی که ساختار و انسجام را به حوزه ای بسیار ناپایدار اضافه کند و در عین حال به بسیاری از افراد نحوه استفاده از یک ابزار ارزشمند را آموزش دهد. مدل‌های دامنه می‌توانند تأثیرات بزرگی در کنترل توسعه نرم‌افزار داشته باشند - صرف نظر از زبانی که در آن پیاده‌سازی می‌شوند یا محیطی که در آن قرار دارند.
یک نکته نهایی اما مهم. یکی از چیزهایی که بیشتر در مورد این کتاب به آن احترام می گذارم این است که اریک از صحبت کردن در مورد زمان هایی که موفق نبوده است، نمی ترسد. اکثر نویسندگان دوست دارند فضایی ایده آل و همه جانبه را حفظ کنند. اریک این موضوع را روشن می کند که مانند اکثر ما، او هم طعم موفقیت و ناامیدی را چشیده است. نکته مهم این است که او می تواند از هر دو آن ها بیاموزد - و مهمتر از آن برای ما این است که او می تواند درس های خود را منتقل کند.
مارتین فولر آوریل ۲۰۰۳
حداقل بیست سال است که، طراحان پیشرو نرم افزار، مدل‌سازی و طراحی دامنه را جزو موضوعات حیاتی می‌دانند، با این حال، به طرز شگفت‌انگیزی در مورد آنچه که باید انجام شود یا چگونه آن را انجام دهیم، نوشته‌های کمی وجود دارد. اگرچه هرگز به طور واضح ساختاربندی نشده است، اما فلسفه‌ای به عنوان یک جریان زیرزمینی در جامعه‌ی برنامه‌نویسی شیءگرا پدیدار شده است، فلسفه‌ای که من آن را طراحی هدایت‌شده توسط دامنه (DDD) می‌نامم.
ویژگی مشترک موفقیت‌ها، یک مدل دامنه‌ی غنی بود که از طریق تکرارهای طراحی تکامل یافت و به بخشی از بافت پروژه تبدیل شد. این کتاب چارچوبی برای تصمیم‌گیری در مورد طراحی و واژگان فنی برای بحث در مورد طراحی دامنه ارائه می‌دهد. این کتاب ترکیبی از بهترین شیوه‌های پذیرفته‌شده به همراه بینش‌ها و تجربیات خودم است. تیم‌های توسعه نرم افزار که با دامنه‌های پیچیده مواجه هستند، می‌توانند از این چارچوب برای رویکرد سیستماتیک به طراحی هدایت‌شده توسط دامنه استفاده کنند.
سه پروژه به عنوان نمونه‌هایی ، گویا از اینکه چگونه رویکرد طراحی دامنه می‌تواند بر نتایج توسعه تأثیر بگذارد، در حافظه من برجسته هستند. اگرچه هر سه پروژه ، نرم‌افزار مفیدی را ارائه کردند، اما تنها یک پروژه به اهداف بلندپروازانه خود دست یافت و نرم‌افزار پیچیده‌ای تولید کرد که نیازهای مداوم سازمان به تکامل را برآورده نمود.
پروژه اول یک سیستم معاملات مبتنی بر وب بصورت ساده و مفید بود ، که به سرعت از مرحله شروع عبور کرد. توسعه‌دهندگان بدون هیچ برنامه‌ریزی مشخصی پیش می‌رفتند، اما این موضوع مانع آنها نمی‌شد زیرا نرم‌افزارهای ساده را می‌توان با توجه کمی به طراحی نوشت. در نتیجه این موفقیت اولیه، انتظارات را برای توسعه‌های آتی بسیار بالا برد. بعد از اتمام نسخه اولیه از من خواسته شد روی نسخه دوم کار کنم. وقتی نگاهی دقیق انداختم، دیدم که پروژه فاقد یک مدل دامنه یا حتی یک زبان مشترک در پروژه است و گرفتار یک طراحی بدون ساختار شده‌اند. مدیران پروژه با ارزیابی من موافق نبودند و من آن کار را رد کردم. در نتیجه یک سال بعد، مدیران پروژه ، تیم خود را در یک منجلاب ایجاد شده از ساختارنیافتگی پروژه اولیه دیدند و نتوانستند نسخه دوم را ارائه دهند. اگرچه استفاده آنها از فناوری نمونه بارز نبود، اما منطق کسب و کار بود که بر آنها غلبه کرده بود . اولین انتشار آنها به طور زودرس به یک سیستم قدیمی با نیاز به نگهداری بالا تبدیل شده بود. شکستن این سقف پیچیدگی نیازمند رویکردی جدی‌تر به طراحی منطق دامنه بود.
در اوایل کارم، خوشبختانه در پروژه‌ای قرار گرفتم که موسسین آن به اهمیت طراحی دامنه تأکید داشتند. این پروژه، به کمک یک طراحی دامنه اولیه با یک موفقیت متوسط شروع شد و یک برنامه کاربردی ساده برای معامله‌گران ارائه داد. اما در این مورد، پس از ارائه نسخه اولیه، توسعه بصورت متوالی دنبال شد. هر تکرار، گزینه‌های جدید هیجان‌انگیزی را برای ادغام و گسترش عملکرد نسخه قبلی باز می‌کرد. تیم توانست با انعطاف‌پذیری و قابلیت‌های در حال گسترش به نیازهای معامله‌گران پاسخ دهد. این مسیر صعودی مستقیماً به یک مدل دامنه دقیق که بارها اصلاح شده و در کد بیان می‌شد تبدیل شد. با کسب اطلاعات جدید تیم از دامنه، مدل عمیق‌تر شد. کیفیت ارتباط نه تنها بین توسعه‌دهندگان بلکه بین توسعه‌دهندگان و متخصصان دامنه نیز بهبود یافت و طراحی، به جای تحمیل بار نگهداری سنگین‌تر، اصلاح و گسترش آن آسان‌تر شد.
متاسفانه، پروژه‌ها صرفا با جدی گرفتن مدل‌ها به چنین چرخه موفقی نمی‌رسند. یکی از پروژه‌های گذشته‌ی من با آرزوهای بلندپروازانه برای ساخت یک سیستم سازمانی جهانی برپایه مدل دامنه آغاز شد، اما پس از سال‌ها ناامیدی، اهداف بلند پروازانه خودش رو کمتر کرد و به رویکردهای سنتی رضایت داد.
تیم پروژه ابزارهای خوبی داشت و درک درستی از کسب و کار؛ همچنین توجه ویژه‌ای به مدل‌سازی داشتند. اما جداسازی نامناسب نقش‌های توسعه‌دهندگان، مدل‌سازی را از پیاده‌سازی جدا کرد و در نتیجه، طراحی منعکس کننده‌ی تحلیل عمیق در حال انجام نبود. در هر صورت، طراحی اشیاء تجاری با جزئیات کافی برای پشتیبانی از ترکیب آنها در برنامه‌های کاربردی پیچیده به قدر کافی دقیق نبود. تکرارهای مکرر منجر به هیچ بهبودی در کد نشد، زیرا سطوح مهارتی توسعه‌دهندگان یکسان نبود و آنها از مجموعه‌ی غیررسمی سبک و تکنیک‌های لازم برای ایجاد اشیاء مبتنی بر مدل که هم‌زمان به عنوان نرم‌افزار عملیاتی کاربردی باشند، آگاه نبودند. با گذشت ماه‌ها، کار توسعه در پیچیدگی گرفتار شد و تیم ، چشم‌انداز منسجم خود از سیستم را از دست داد. پس از سال‌ها تلاش، پروژه نرم‌افزاری متوسطی تولید شد، اما تیم از بلندپروازی‌های اولیه‌ی خود دست کشیده بود و به رویکردی سنتی بسنده کرد.
