Domain-Driven Design Quickly

🔹 بخش ۱: هدف DDD

Domain-Driven Design یعنی «طراحی نرم‌افزار با محوریت دامنه (Domain)».
به زبان ساده، DDD می‌گوید:

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

🔸 دامنه (Domain) یعنی چه؟

دامنه همان دنیای مسئله است — یعنی فضای مفهومی که کسب‌وکار در آن کار می‌کند.

مثلاً:

• برای یک شرکت بانکی، دامنه یعنی: حساب، تراکنش، کاربر، اعتبار، سود.

• برای یک پلتفرم سفارش غذا، دامنه یعنی: مشتری، رستوران، منو، سفارش، پرداخت.

هرچه دانش و درک تیم از دامنه دقیق‌تر باشد، مدل نرم‌افزاری که می‌سازد، به واقعیت نزدیک‌تر است و احتمال شکست سیستم کمتر می‌شود.

🔹 بخش ۲: مدل دامنه (Domain Model)

مدل دامنه نمایش مفهومی از واقعیت کسب‌وکار است — شامل موجودیت‌ها (Entities)، مقدارها (Value Objects)، قوانین، رفتارها و ارتباطات.

مدل فقط دیاگرام یا دیتاستراکچر نیست؛ یک زبان مشترک بین توسعه‌دهندگان و کارشناسان دامنه است.

📘 نکتهٔ کلیدی:
DDD می‌گوید که مدل دامنه باید:

1. از دل گفت‌وگو با متخصصان کسب‌وکار بیرون بیاید.

2. در کد منعکس شود — نه فقط روی وایت‌برد.

🔸 Ubiquitous Language (زبان فراگیر)

زبان فراگیر یعنی واژگان مشترکی که بین تیم فنی و بیزنسی یکسان معنا دارند و در کل پروژه، از تحلیل تا کدنویسی، استفاده می‌شوند.

مثلاً در سیستم بانکی اگر واژه‌ی “Account” در مستندات، کد و گفتگو همه یک معنی دقیق داشته باشد، تیم می‌تواند هماهنگ فکر کند و طراحی واضح‌تری بسازد.

📌 اگر زبان تیم دوگانه باشد (مثلاً کارشناس بگوید «کاربر ویژه» ولی برنامه‌نویس در کد بنویسد VIPUser بدون درک تفاوتش)، مدل از واقعیت جدا می‌شود.

🔹 بخش ۳: Bounded Context (مرزِ زمینه)

یکی از مهم‌ترین مفاهیم فصل ۱ است.

Bounded Context یعنی:

هر مدل دامنه فقط در یک «زمینهٔ مشخص» معتبر است.

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

📍 مثال:
در یک شرکت تجارت الکترونیک:

• دامنه‌ی «فروش» (Sales) با مفاهیم سفارش و تخفیف سروکار دارد.

• دامنه‌ی «انبارداری» (Inventory) با موجودی و تحویل کالا کار می‌کند.

• دامنه‌ی «صورت‌حساب» (Billing) با پرداخت و فاکتور سر و کار دارد.

هرکدام از این‌ها یک Bounded Context است.
درون هر Context، «زبان فراگیر»، «قوانین» و «مدل‌ها» خاص خودشان را دارند.
ولی ارتباط بین Contextها از طریق integration یا contractهای مشخص انجام می‌شود (مثلاً API یا Event).

🔸 مشکل بزرگ بدون Bounded Context

وقتی تیم سعی کند برای کل سیستم فقط یک مدل سراسری بسازد، در عمل مدل بیش‌ازحد پیچیده می‌شود و معنی واژه‌ها در بخش‌های مختلف متناقض می‌گردد.
مثلاً کلمه‌ی “Customer” ممکن است در بخش فروش یعنی «خریدار»، ولی در بخش پشتیبانی یعنی «هرکسی که تماس گرفته».

Bounded Context جلوی این آشفتگی را می‌گیرد، چون می‌گوید:

هر واژه و مفهوم فقط در مرز مشخص خودش معنا دارد.

🔹 بخش ۴: چرا DDD مهم است؟

چون پروژه‌های نرم‌افزاری معمولاً در سه دامنه شکست می‌خورند:

1. سوء‌تفاهم بین بیزنس و توسعه‌دهنده

2. پیچیدگی بی‌دلیل در مدل

3. نبود مرز مشخص بین زیرسیستم‌ها

DDD با:

• تمرکز روی دامنه (Domain)

• ساخت زبان مشترک (Ubiquitous Language)

• تعریف مرزها (Bounded Context)
  به تیم کمک می‌کند سیستم‌هایی بسازد که هم قابل فهم و هم قابل گسترش باشند.

🔸 خلاصه تصویری ذهنی

💬 در پایان فصل ۱، باید بتوانی:

• تفاوت بین Domain و Model را توضیح دهی.

• در گفتگو با بیزنس از Ubiquitous Language استفاده کنی.

• سیستم را به چند Bounded Context بشکنی.

• بفهمی چرا DDD درباره‌ی «تکنولوژی» نیست بلکه درباره‌ی «تفکر دامنه‌محور» است.