Domain Driven Design (DDD)
این مفهوم به ایجاد نگاشت بین مفاهیم موجود در کسب‌وکار و مصنوعات معماری می‌پردازد. این رویکرد از این رو صورت می‌گیرد که نرم‌افزار مطابقت بیشتری با خواسته‌ی ذینفعان داشته باشد همچنین درک بهتری از نیاز ذینفعان برای معماران نرم‌افزار ایجاد شود. نکته‌ی قابل توجه این است که DDD را نمی‌توان معماری به حساب آورد.
· مفاهیم: در این بخش اصطلاحاتی که در آن کسب‌وکار موجود است و معانی آنها مورد بررسی قرار می‌گیرد.
· طراحی استراتژیک: این بخش به بررسی هدف‌های اصلی پروژه و زمینه‌های آن و محدوده‌ی کار به همراه کل ذینفعان می پردازد.
· طراحی تاکتیکی: بخشی از DDD که به بررسی موجودیت‌ها، خدمات و ماژول‌های لازم در پروژه با توجه به موارد قبلی می‌پردازد.
· طراحی معماری: به سبک معماری که می‌تواند در DDD استفاده شود و معماری‌هایی مانند هگزاگونال، لایه‌ای، CQRS و... اشاره دارد.
مفاهیم سطح بالایی که در این مدل استفاده می‌شوند به شرح زیر است:
· موجودیت (Entity): شی که با رشته پیوستگی آن تعریف می‌شود برخلاف اشیاء سنتی که با ویژگی‌هایشان مشخص می‌شوند.
· شی‌ارزشی (Value Object): شی تغییرناپذیری که دارای صفات است، اما هویت جداگانه ندارد.
· رویداد دامنه (Domain Event): شی که برای ردیابی رویدادهایی که کارشناسان دامنه به آن اهمیت می‌دهند استفاده می‌شود.
· خوشه‌ای(Aggregate): به مجموعه‌ای از موجودیت‌ها و اشیا ارزشی با مرزهای مشخص در اطراف گروه که به جای اینکه به هر موجویت یا شی مقداری داده شود تا کاری را انجام دهد به مجموعه‌ای از اقلام خوشه مقدار اختصاص داده شده است. هم‌اکنون اشیا خارجی به شی داخلی دسترسی ندارند بلکه به آیتم ریشه‌ی مجموع دسترسی خواهند داشت.
· خدمات(service.):به عملیاتی از منطق کسب و کار گفته می‌شود که هدف مشخصی را دارد و در قلمروی اشیا نیستند.
· مخازن(Repositories): سرویسی است که از یک رابط جهانی برای دسترسی به تمام موجودیت ها و اشیاء ارزشی که در یک مجموعه خوشه‌ی خاص هستند استفاده می کند. روش‌هایی باید تعریف شوند تا امکان ایجاد، اصلاح و حذف اشیاء در مجموعه را فراهم کنند. با این حال، با استفاده از این سرویس مخزن پرس و جوهای داده ایجاد می‌شود . هدف حذف چنین پرس‌وجوهایی می‌باشد همچنین نباید آن را با مخازن رایج کنترل اشتباه گرفت.
· کارخانه(Factories): DDD استفاده از یک کارخانه را پیشنهاد می‌کند که منطق ایجاد اشیاء و مصالح پیچیده را در بر می‌گیرد و تضمین می‌کند که مشتری از عملکرد درونی دستکاری اشیا اطلاعی ندارد.
مزایای طراحی دامنه محور
ارتباطات را آسان می کند: با تأکید اولیه بر ایجاد یک زبان مشترک و همه جا حاضر مرتبط با مدل دامنه پروژه، تیم ها اغلب ارتباط در کل چرخه عمر توسعه را بسیار آسان تر می بینند. به طور معمول، DDD هنگام بحث در مورد جنبه های برنامه به اصطلاحات فنی کمتری نیاز دارد، زیرا زبان فراگیر احتمالاً اصطلاحات ساده تری را برای اشاره به جنبه های فنی تر تعریف می کند.
انعطاف‌پذیری را بهبود می‌بخشد: از آنجایی که DDD به شدت حول مفاهیم تحلیل و طراحی شی گرا است، تقریباً همه چیز در مدل دامنه مبتنی بر یک شی خواهد بود و بنابراین کاملاً ماژولار و محصور شده است و اجازه می دهد تا اجزای مختلف، یا حتی کل سیستم به عنوان یک کل، به طور منظم و مداوم تغییر و بهبود یابد.
بر روی اینترفیس دامنه تاکید می کند: از آنجایی که DDD بر ایجاد مفاهیم دامنه و آنچه متخصصان دامنه در پروژه توصیه می کنند است، در نتیجه برخلاف برنامه هایی که در درجه اول بر UI/UX تاکید دارند، اغلب برنامه هایی را تولید می کند که دقیقاً برای دامنه مورد نظر مناسب و نماینده آن هستند. در حالی که یک تعادل آشکار مورد نیاز است، تمرکز بر دامنه به این معنی است که یک رویکرد DDD می تواند محصولی تولید کند که به خوبی با مخاطبان مرتبط با آن دامنه ارتباط برقرار کند.
معایب طراحی دامنه محور:
به تخصص قدرتمند دامنه نیاز دارد: حتی با وجود ماهرترین ذهن‌های فنی که روی توسعه کار می‌کنند، اگر حداقل یک متخصص دامنه در تیم وجود نداشته باشد که از جزئیات دقیق حوزه ی موضوعی که برنامه در نظر گرفته شده است مطلع نباشد، همه چیز بیهوده است. در برخی موارد، طراحی دامنه محور ممکن است به ادغام یک یا چند عضو تیم خارجی نیاز داشته باشد که می توانند به عنوان متخصص دامنه در طول چرخه عمر توسعه عمل کنند.
تمرین‌های تکراری را تشویق می‌کند: در حالی که بسیاری این را یک مزیت می‌دانند، نمی‌توان انکار کرد که تمرین‌های DDD قویاً بر تکرار ثابت و یکپارچگی مداوم برای ساختن یک پروژه انعطاف‌پذیر است که می‌تواند در صورت لزوم خود را تنظیم کند. برخی از سازمان‌ها ممکن است با این شیوه‌ها مشکل داشته باشند، به‌ویژه اگر تجربه گذشته آنها تا حد زیادی با مدل‌های توسعه کمتر انعطاف‌پذیر، مانند مدل آبشاری یا موارد مشابه مرتبط باشد.
برای پروژه های بسیار فنی مناسب نیست: در حالی که DDD برای برنامه هایی که پیچیدگی دامنه زیادی دارند (که منطق کسب و کار نسبتاً پیچیده است) عالی است، DDD برای برنامه هایی که پیچیدگی دامنه حاشیه ای دارند اما برعکس پیچیدگی فنی زیادی دارند چندان مناسب نیست. از آنجایی که DDD به شدت بر نیاز (و اهمیت) متخصصان دامنه برای تولید زبان مناسب فراگیر و مدل دامنه ای که پروژه بر اساس آن استوار است تأکید می کند، پروژه ای که از نظر فنی فوق العاده پیچیده باشد ممکن است برای کارشناسان دامنه چالش برانگیز بوده و مشکلاتی را ایجاد کند.
منابع:
[1]: https://www.infoq.com/articles/ddd-in-practice/
[2]: https://thedomaindrivendesign.io/what-is-ddd/
این مطلب بخشی از تمرین درس معماری نرم افزار در دانشگاه شهید بهشتی می باشد.
