واقعیتش هیچ وقت معنی‌دار نیست که در مورد راه‌حل صحبت کنیم تا زمانی که در مورد مسئله توافق نکرده ایم، و همچنین معنی‌دار نیست که در مورد مراحل اجرایی و توسعه صحبت کنیم تا زمانی که در مورد راه‌حل توافق نکنیم. این جمله به این جمله تاکید میکنه که قبل از آنکه به جزئیات راه‌حل یا اجرای پروژه بپردازیم، باید ابتدا در مورد مسئله و نیازهای واقعی مشتری یا پروژه توافق کنیم.
این ابتدایی‌ترین مرحله در هر فرآیند توسعه نرم‌افزار یا پروژه است که به تعیین مسئله و تعریف راه‌حل های مناسب برای آن می‌پردازد. به عبارت دیگر، ابتدا باید مشکلات را مشخص کرده و سپس راه‌حل مناسب را ایجاد کنیم و در نهایت به مراحل اجرایی بپردازیم.
از این رو متدولوژی DDD بر 2 قسمت اصلی تقسیم میشود :
1- طراحی استراتژی
2- طراحی تکنیکال
در واقع بخش طراحی استراتژی بر روی جواب دادن به سوالاتی مانند چه چیزی و چرا تمرکز میکند. " چه نرم افزاری رو ما داریم میسازیم و اصلا برای چی داریم میسازیم ؟"
اما قسمت و یا بخش طراحی تکنیکال به سوال چطور این کار رو باید انجام بدیم تمرکز میکند. " چطور این نرم افزار رو قرار است بسازیم ؟"
ما مسیر جذاب خودمون رو با توضیحاتی در مورد طراحی الگو و قواعد طراحی دامنه محور در بخش طراحی استراتژی ادامه خواهیم داد.
در فصل 1، چیزی که قراره باهم در موردش بیشتر صحبت کنیم این هست که چگونه استراتژی کسب‌وکار یک شرکت را تجزیه و تحلیل کنیم: اصلا اون کسب و کار چه ارزشی برای مصرف‌کنندگان ارائه می‌دهد و چگونه با شرکت‌های دیگر در صنعت رقابت میکند. ما اجزای این ساختار را به صورت دقیقتری بررسی میکنیم و تاثیرات این اجزا بر تصمیمات طراحی نرم افزار را هم تحلیل و بررسی قرار میدیم.
فصل 2 به معرفی یکی از مفاهیم اساسی طراحی دامنه محور (Domain-driven design) برای درک دامنه کسب‌وکار می‌پردازد: زبان فراگیر یا زبان یکپارچه (Ubiquitous Language).
در این بخش به این موضوع میپردازیم که چگونه یک زبان فراگیر و یا یکپارچه را بوجود بیاوریم و از آن برای ایجاد یک درک مشترک بین تمام صاحب‌نظران مرتبط با پروژه استفاده کنیم.