🧠 درک Domain-Driven Design (DDD) — راهنمای جامع توسعه‌دهندگان

«پیچیدگی دشمن شما نیست. پیچیدگی رام‌نشده دشمن شما است.»
— اریک ایوانز، Domain-Driven Design

🚀 مقدمه

سیستم‌های نرم‌افزاری مدرن روزبه‌روز پیچیده‌تر می‌شوند، به‌خصوص در حوزه‌هایی مثل فین‌تک، بهداشت و درمان، تجارت الکترونیکی یا لجستیک. وقتی راه‌حل‌های فنی از نیازهای کسب‌وکار فاصله می‌گیرند، تیم‌ها کند می‌شوند، باگ‌ها افزایش می‌یابند و ارائه ویژگی‌ها دشوارتر می‌شود.

Domain-Driven Design (DDD) یک رویکرد استراتژیک است که معماری نرم‌افزار شما را با دامنه‌های واقعی کسب‌وکار (business domains) هماهنگ می‌کند.

بیایید بفهمیم DDD چیست، چرا اهمیت دارد و چگونه به‌صورت عملی از آن استفاده کنیم.

🔍 DDD چیست؟

Domain-Driven Design (DDD) فلسفه‌ای در طراحی نرم‌افزار است که توسط اریک ایوانز در کتاب مشهورش در سال ۲۰۰۳ معرفی شده است.

در هسته‌ی آن:

DDD دامنه — یعنی منطق کسب‌وکار و مسئله دنیای واقعی — را در مرکز نرم‌افزار قرار می‌دهد.

به جای اینکه مستقیماً وارد تعریف جداول پایگاه داده یا APIها شویم، DDD با درک دامنه اصلی کسب‌وکار و همکاری عمیق با کارشناسان دامنه (domain experts) آغاز می‌شود.

💡 سه رکن اصلی DDD

1. Ubiquitous Language (زبان فراگیر):
   استفاده از زبان مشترک در کد، کارشناسان دامنه و مستندات.

2. Strategic Design (طراحی استراتژیک):
   تقسیم دامنه به bounded contexts (زمینه‌های محدود شده) برای مدیریت پیچیدگی در مقیاس.

3. Tactical Design (طراحی تاکتیکی):
   استفاده از بلوک‌های سازنده مثل Entities (موجودیت‌ها)، Value Objects (اشیاء مقداری)، Aggregates (تجمع‌ها) و غیره.

---

🧱 طراحی تاکتیکی: بلوک‌های اصلی ساختار

1. Entity (موجودیت)

• شیئی با هویت یکتا که در طول زمان حفظ می‌شود.
• مثال: Order، User، Invoice.

1class Order {  
2    UUID id;  
3    List<OrderItem> items;  
4    BigDecimal totalAmount;  
5}

2. Value Object (شیء مقداری)

• هویت ندارد و فقط با خصوصیاتش تعریف می‌شود.
• غیرقابل تغییر (immutable) و قابل تعویض.
• مثال: Address، Money.

1class Address {  
2    String street;  
3    String city;  
4    String country;  
5}

3. Aggregate (تجمع)

• گروهی از موجودیت‌ها و اشیاء مقداری که به عنوان یک واحد واحد در نظر گرفته می‌شوند.
• یک "ریشه تجمع" (aggregate root) دارد که قواعد (invariants) را تضمین می‌کند.

مثال:
Order ریشه تجمع است؛ OrderItem بخشی از آن است.

4. Repository (مخزن)

• اینترفیس برای یافتن و ذخیره‌سازی تجمع‌ها (aggregates).

1interface OrderRepository {  
2    Order findById(UUID id);  
3    void save(Order order);  
4}

5. Domain Service (خدمات دامنه)

• منطق دامنه‌ای که به‌طور طبیعی در هیچ موجودیت منفرد جای نمی‌گیرد را کپسوله می‌کند.

1class PaymentService {  
2    void charge(Customer customer, Money amount);  
3}

---

🧠 طراحی استراتژیک: مدیریت پیچیدگی

🧩 Bounded Context (زمینه محدود شده)

زمینه محدوده‌ای واضح در اطراف بخشی از دامنه است که در آن یک مدل مشخص کاربرد دارد.

مثال:

• زمینه Order Management در مقابل زمینه Inventory Management.
• اصطلاح "Product" ممکن است در هر دو زمینه معنای متفاوتی داشته باشد.

🔌 Context Mapping (نقشه‌برداری زمینه)

تعریف ارتباط بین زمینه‌ها:

• Shared Kernel (هسته مشترک)
• Customer-Supplier (مشتری-عرضه‌کننده)
• Anticorruption Layer (لایه ضد فساد که بین مدل‌ها ترجمه می‌کند)
• Published Language (زبان منتشر شده، مانند رویدادها و APIها)

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

تمام ذینفعان — توسعه‌دهندگان، تست‌کنندگان، کارشناسان دامنه — باید همان زبان را به‌کار ببرند.

✅ اصطلاحات دامنه را در موارد زیر استفاده کنید:

• نام کلاس‌ها
• نام متدها
• مستندات
• مکالمات

از اصطلاحات فنی مثل “DTO”، “DBEntity”، یا “ServiceImpl” در کد اصلی دامنه پرهیز کنید.

---

🏗️ مثال واقعی: سیستم تجارت الکترونیکی

بیایید DDD را در دامنه‌ی پردازش سفارش به‌کار ببریم.

🔹 Bounded Contexts

• Order Context (زمینه سفارش)
• Payment Context (زمینه پرداخت)
• Inventory Context (زمینه انبار)
• Shipping Context (زمینه حمل‌ونقل)

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

🔹 Ubiquitous Language

اصطلاح حوزه (Domain Term)	شرح
Order	قصد مشتری برای خرید
Item	محصول در یک سفارش
Fulfillment	فرایند ارسال سفارش

🔹 مدل‌سازی تاکتیکی (زمینه سفارش)

1class Order {  
2    UUID id;  
3    Customer customer;  
4    List<OrderItem> items;  
5    OrderStatus status;  
6    
7    void addItem(Product product, int quantity) { ... }  
8    void confirm() { ... }  
9}

---

📦 DDD و معماری میکروسرویس

DDD به‌خوبی با معماری میکروسرویس‌ها همخوانی دارد؛ جایی که هر bounded context می‌تواند به یک میکروسرویس تبدیل شود.

اما توجه کنید:

• از مدولار مونولیت‌ها (modular monoliths) شروع کنید، سپس سرویس‌ها را به تدریج جدا کنید.
• از تقسیم زودهنگام خودداری کنید!

---

🛠️ ابزارها و فریم‌ورک‌ها

• Java/Kotlin: Spring Boot + Axon Framework
• Node.js: NestJS CQRS + TypeORM
• .NET: MediatR + EF Core
• ابزارهای DDD: EventStorming، Domain Storytelling

---

🧩 الگوهای پرکاربرد در DDD

الگو	هدف
CQRS	تفکیک مدل‌های خواندن و نوشتن
Event Sourcing	ذخیره وضعیت به صورت دنباله‌ای از رویدادها
Hexagonal Architecture	حفظ پاکی دامنه، جدا کردن از زیرساخت
Clean Architecture	جداسازی لایه‌ای مسئولیت‌ها

---

⚠️ چالش‌ها در DDD

• منحنی یادگیری بالا
• نیاز به همکاری نزدیک با کارشناسان دامنه
• ممکن است برای برنامه‌های ساده CRUD زیاد باشد
• مدل‌سازی پیچیده = فکر کردن زیاد از ابتدا

---

🧠 تغییر ذهنیت در DDD

به جای پرسیدن:

«به چه جداول پایگاه داده نیاز دارم؟»

بپرسید:

«رفتار اصلی دامنه‌ای که می‌خواهم مدل‌سازی کنم چیست؟»

---

🧘 سخن پایانی

DDD معجزه نمی‌کند.
اما در دامنه‌های پیچیده، به تیم شما زبان مشترک، راهبرد مدل‌سازی و انضباط طراحی می‌دهد تا نرم‌افزاری بسازید که به‌خوبی بازتاب‌دهنده کسب‌وکار باشد.

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

---

📚 مطالعه بیشتر

• Domain-Driven Design — Eric Evans
• Implementing DDD — Vaughn Vernon
• Domain Storytelling — Hölldobler و همکاران
• Learning DDD with EventStorming — Alberto Brandolini
• مرجع DDD از Eric Evans (رایگان)