🔭 تاریخچه و زمینه پیدایش Domain-Driven Design

اوایل دههٔ ۲۰۰۰ شرکت‌های خیلی بزرگ (بانک‌ها، بیمه، و …) با سیستم‌های نرم‌افزاری‌ای روبه‌رو بودند که:

- دامین‌های با پیچیدگی خیلی بالا داشتند (مثل قوانین کسب‌وکار پرشمار و در حال تغییر).

- گپ ارتباطی وحشتناکی بین تحلیلگرها و برنامه‌نویس‌ها وجود داشت؛ اصطلاحات یکی برای دیگری نامفهوم بود.

- هر تغییر کوچک به موجی از regression bugها و استرس انتشار تبدیل می‌شد.

توی چنین شرایطی، Eric Evans می‌گه: «بیایید به جای تمرکز صِرفن روی لایه‌های فنی، قلب مسأله—یعنی دامنه—رو محور کار بگذاریم.» نتیجه شد متدولوژی Domain-Driven Design که توی کتاب معروف «آبی» در سال ۲۰۰۳ متولد شد و ‌بعدتر با کارهای Vaughn Vernon، Jimmy Nilsson و بقیه گسترش پیدا کرد.

برخی مفاهیم پایه در DDD:

- مفهوم Ubiquitous Language
زبان مشترک بین همهٔ ذی‌نفعان. کلاس، جدول DB و اسلاید ارائه باید از یک واژه برای یک مفهوم استفاده کنند، و یک واژه باید همه جا معنی یکسان داشته باشه.

- مفهوم Bounded Context
مرزهایی شفاف برای معنی واژه‌ها. «سفارش» در حسابداری ≠ «سفارش» در انبار.

- مفهوم Aggregate
یک خوشه (گروه) از آبجکت‌ها، با یک ریشهٔ واحد که می‌شه به‌صورت واحد تلقی کردشون.

- مفهوم Context Map
نقشهٔ روابط بین Bounded Contextها؛ شامل پیوندهای همکار، مشتری–تأمین‌کننده و…

- مفهوم Strategic Design
هنر تشخیص اینکه کِی باید دامنه رو بشکنیم و تیم رو حولش سازمان‌دهی کنیم.

آیا DDD برای همه است؟ نه دقیقاً!
توی «مطلب قبل» دربارهٔ وسوسهٔ ترندها گفتم، DDD هم قربانی حباب‌ها شده. نشونه‌های انتخاب اشتباه:

- دامنه ساده است (CRUD سرراست، منطق پیچیده‌ای هم نداره) ولی تیم حتماً می‌خواد Bounded Context تعریف کنه و Event Storming برگزار کنه!

- ابزارهای تحلیلی، تست، مستندسازی و DevOps هنوز بالغ نیستند اما «می‌خواهیم معماری تمیز + DDD + مایکروسرویس» رو با هم پیاده کنیم.

- تیم کوچک است ولی هر کانتکست رو توی یک ریپو جداگانه Deploy می‌کنه و نصف زمانش صرف هماهنگی بین ریپوها می‌شه.

یادمون نره: DDD هزینه داره—هم آموزشی، هم طراحی، هم نگهداری.
اگر درد پیچیدگی دامنه رو حس نمی‌کنیم، این دارو تلخ و بی‌فایده است!!

چرا لزوماً هر معماری دامین-سنتریک، DDD نیست؟!
— بعدتر دراین‌باره خواهم نوشت که هر گردی گردو نیست!! پیاده‌سازی Clean / Hexagonal / Onion به معنی DDD نیست!

«توی DDD، معماری کد فقط یک لایه از ماجراست؛ موفقیت زمانی رقم می‌خوره که ساختار سازمانی و فرایندهای تیم هم با مرزهای دامنه منطبق شن. اگر تیم کوچکه و دامنه پیچیدگی بالایی نداره، صرف داشتن لایهٔ Domain یا استفاده از معماری Clean، شما صاحب DDD نمی‌شید.»

🔔 اگر علاقه‌مند بودید، روز ۴ خرداد (۲۵ می) ساعت ۱۹:۳۰ به وقت تهران جلسه‌ای به همت انجمن DDD ایران برگزار می‌شه که اگر عمر و فرصتی بود، در این مورد به تفصیل صحبت خواهم کرد. اطلاعات ایونت رو توی کامنت قرار خواهم داد.

💬 نظر؟ تجربه؟