اصولا برای حل مسئله در مسائل مهندسی از روش تقسیم و غلبه استفاده می کنیم. یک دامین بزرگ از بخش های مختلفی تشکیل شده است. این بخش ها از نظر نیازمندی، vocabulary یا واژگان و business expert با هم متفاوت می باشند. همچین ارزش و یا پیچیدگی این بخش ها نیز می تواند با هم متفاوت باشد. در رویکردی که در DDD وجود دارد که اصطلاحا به آن Strategic Design گفته می شود، مرزهای درونی یک سیستم را شناسایی می کنیم و به عنوان واحدهای مستقل به آن ها نگاه می کنیم. همچنین تیم های مستقلی را می توانیم برای آن ها تشکیل دهیم.
در شرایطی که یک domain به subdomainهای کوچک تر شکسته می شود، با مسائل کوچک تری برای حل آن ها روبرو خواهیم شد. برای مثال اگر یکی از subdomainهای سیستم خود را به عنوان CRM در نظر گرفته باشیم، برنامه نویسی که روی CRM کار می کند می تواند در عمق بیشتری روی آن تمرکز کند و نیازی ندارد تمام نیازها و قوانین سیستم را بداند.
در نهایت هر کدام از این subdomainها تبدیل به یک پروژه می شوند که می توانند تکنولوژی، معماری و دیتابیس مستقل خود را داشته باشند.
مفاهیم subdomain و domain در فضای مساله (Problem Space) مطرح می شوند که ممکن است به واقعیت تبدیل نشوند و Bounded Context در فضای راه حل (Solution Space) تعریف می شود.
اگر بر روی هر کدام از subdomainها تمرکز کنیم، ممکن است با گراف بزرگی از مدل ها روبرو شویم که با هم در تعامل هستند و مدیریت آن برای ما سخت است. در حوزه DDD، غیر از مفهوم Strategic Design، رویکرد دیگری به نام Tactical Design نیز وجود دارد. موضوعی که در این رویکرد با آن روبرو هستیم، شکستن گراف مدل به اجزای کوچک تر و برخورد با آن اجزا به عنوان یک واحد مستقل می باشد. در DDD این مفهوم را Aggregate می نامیم. از طریق شناسایی invariantها، این گراف به اجزای کوچک تر شکسته می شود.
اجزای سازنده یک aggregate، می تواند از entity یا value object تشکیل شده باشد. هر جزئی در modeling که دارای شناسه می باشد و آن را از طریق شناسه، شناسایی و به آن اشاره می کنیم، به عنوان entity در نظر گرفته می شود. گاهی اوقات نیز با اجزایی روبرو هستیم که شناسه ندارند و نقشی که در domain دارند بیشتر توصیفی است و با مقادیری که دارند شناسایی می شوند. به این اجزا value object گفته می شود.
برای مدل کردن value objectها چند موضوع را در نظر می گیریم. موضوع اول Attribute-Based Equality می باشد. مساوی بودن دو value object بسته به مقادیر آن ها می باشد. موضوع بعدی Identity-Less می باشد. value objectها را می توانیم با هم ترکیب کنیم بنابراین Combinable بودن نیز موضوع بعدی می باشد. Immutable بودن نیز از ویژگی های value object است. بنابراین یک value object را تغییر نمی دهیم و اگر نیاز باشد از یک شی جدید استفاده می کنیم. Self-Validating بودن نیز از ویژگی های مهم یک value object است. یک value object وظیفه دارد جلوی مقادیر نامعتبر را بگیرد.
در DDD، مفهومی دیگری به نام Domain Event داریم که رویدادهایی هستند که اتفاق می افتند. در حالت معمول domain event می تواند کاربردهای مختلفی داشته باشد. برای مثال اتفاقی که در یک aggregate می افتد و می خواهیم تاثیر آن را در aggregate دیگر ببینیم، می توانیم از event استفاده می کنیم. یا قصد داشته باشیم که از طریق یک Bus به بیرون از پروژه یک رویداد را اطلاع رسانی کنیم نیز می توانیم از event استفاده کنیم. اگر از event sourcing استفاده کنیم، eventها جزو بخش های اصلی domain ما هستند و به عنوان دیتای اصلی ما ذخیره سازی می شوند. در قالب یک کلاس به همراه داده های مورد نیاز در دامین ما پیاده سازی می شوند و immutable هستند.
