خواندن ۸ دقیقه·۴ سال پیش

Domain Driven Design - بخش دوم

بررسی انواع Core Domain و مفاهیم مرتبط

در این بخش به بررسی انواع مختلف Core Domain و موضوعات مرتبط با آن در چارچوب Domain-Driven Design (DDD) می‌پردازیم. همچنین مفاهیمی مانند Bounded Context ،Context Mapping و الگوهای ارتباطی بین بخش‌های مختلف سیستم را مورد تحلیل قرار می‌دهیم.

مفهوم Core Domain و اهمیت آن در طراحی سیستم

در طراحی سیستم‌های نرم‌افزاری، Core Domain به بخشی از سیستم اشاره دارد که بیشترین ارزش کسب‌وکار(Business Value) را ایجاد می‌کند. این بخش معمولاً کوچک‌ترین قسمت سیستم است، اما بیشترین تمرکز و تلاش تیم توسعه را به خود اختصاص می‌دهد.

موضوعی که توسط آقای Eric Evans در راستای قانون 80-20 مطرح می شود، بیان می‌کند که Core Domain تنها 20 درصد از use caseهای کاربر را شامل می‌شود، اما 80 درصد از تلاش تیم توسعه را به خود اختصاص می‌دهد. این بدان معناست که شناسایی و تمرکز بر روی این 20 درصد، می‌تواند بیشترین ارزش را برای کسب‌وکار به همراه داشته باشد.

در strategic design، با در نظر گرفتن نمودار زیر، اگر محور y را پیچیدگی در نظر بگیریم و محور x مزیت رقابتی ما در بازار باشد، هر چقدر x بزرگتر باشد موفقیت بیشتری برای business ما در بازار به همراه خواهد داشت. بنابراین core domain از لحاظ business differentiation، در بالای محور x قرار دارد. در مورد generic domains و supporting domains، این موضوع اهمیت کمتری دارد. درصد کمتری از supporting domainها هستند که در بازار می تونن مزیت رقابتی ایجاد کنند. یک business، دارای featureهایی است که آنها را تحت عنوان mission critical می شناسیم. وجود آنها الزامی است و فعالیت business ما به آنها وابسته است. این featureها عمدتا از سطح پیچیدگی بالایی برخوردار هستند و در core domain قرار دارند.

انواع Core Domain

1. Core Domain کوتاه‌مدت (Short-Term Core Domain)

برخی از نیازمندی‌ها و فعالیت‌ها ممکن است به‌صورت موقت به عنوان Core Domain در نظر گرفته شوند. برای مثال، یک سازمان ممکن است برای جذب بازار، بر روی توسعه یک سیستم تخفیف‌دهی تمرکز کند. این نیازمندی‌ها ممکن است به‌مرور زمان تغییر کنند یا حتی حذف شوند.

2. Core Domain پنهان (Hidden Core Domain)

در برخی موارد، ممکن است بخش‌هایی از سیستم که به عنوان Supporting Domain در نظر گرفته شده‌اند، به‌مرور زمان به Core Domain تبدیل شوند. این تغییر ممکن است به دلیل نیاز بازار یا اشتباهات تحلیلی رخ دهد.

3. Core Domain فراگیر (Generalized Core Domain)

گاهی اوقات یک ویژگی که قبلاً به عنوان مزیت رقابتی در نظر گرفته می‌شد، ممکن است به‌مرور زمان توسط رقبا نیز پیاده‌سازی شود و دیگر مزیت رقابتی محسوب نشود. در این حالت، استراتژی سیستم باید تغییر کند تا Core Domain جدیدی شناسایی شود.

Bounded Context

در برخی موارد، ممکن است subdomain و bounded context، اشتباه گرفته شوند.

مواردی که تا این لحظه به آن ها پرداخته شد در حوزه Problem Space یا فضا و شناخت مسئله قرار می گیرند. به این معنی که ما هنوز وارد فضای راه حل نشده ایم.

تصویر بالا، problem space را نشان می دهد. تیم توسعه و business expertها از طریق فرآیندهای knowledge crunching و ubiquitous language که DDD بر روی آن تاکید می کند، knowledge کلی در یک نرم افزار را استخراج می کنند. این knowledge به حوزه های کاری مختلف شکسته می شود. بعد از آن، روی آن ها ارزش گذاری می شود.

موضوع در Solution Space یا فضای راه حل ممکن است مقداری متفاوت باشد.

مفهوم Bounded Context به یک پروژه فیزیکی اشاره دارد که در آن کدهای سیستم پیاده‌سازی می‌شوند. این مفهوم با Subdomain متفاوت است، اگرچه در حالت ایده‌آل هر Subdomain در یک Bounded Context پیاده‌سازی می‌شود. با این حال، در عمل ممکن است این دو مفهوم یک به یک نباشند. برای مثال، در سیستم‌های قدیمی (Legacy Systems)، ممکن است چندین Subdomain در یک Bounded Context پیاده‌سازی شده باشند.

مفهوم bounded context یا BC، یک پروژه نرم افزاری است که boundary یا مرز مشخصی دارد. در حالت ایده‌آل architecture و team مربوط به خودش را دارد و ممکن است language مربوط به خودش را نیز داشته باشد و به عنوان یک واحد autonomous یا مستقل در پروژه ما عمل می کند.

معیارهای تشخیص Bounded Context

1. زبان (Language):تغییر در زبان و واژگان مورد استفاده در یک بخش از سیستم می‌تواند نشان‌دهنده مرز بین Bounded Contextها باشد.

2. چشم‌انداز (Perspective):تفاوت در نگرش و دیدگاه نسبت به یک مفهوم خاص نیز می‌تواند مرز بین Bounded Contextها را مشخص کند.

3. تخصص‌های دامنه(Domain Expertise):وجود متخصصان مختلف در حوزه‌های مختلف نیز می‌تواند نشان‌دهنده مرزهای متفاوت بین Bounded Contextها باشد.

Context Mapping

به فرآیند شناسایی و تعریف روابط بین BCها اشاره دارد. این روابط می‌توانند به شکل‌های مختلفی تعریف شوند:

Anti-Corruption Layer

این لایه به عنوان یک واسطه عمل می‌کند و از رخنه مفاهیم یک BC به دیگری جلوگیری می‌کند. برای مثال، زمانی که یک BC نیاز به استفاده از داده‌های BC دیگر دارد، ACL این داده‌ها را به فرمت مناسب تبدیل می‌کند.

Shared Kernel

در برخی موارد، ممکن است بخش‌هایی از مدل بین دو BC مشترک باشند. استفاده از Shared Kernel می‌تواند هزینه‌های ترجمه و یکپارچه‌سازی را کاهش دهد، اما باید توجه داشت که این روش می‌تواند وابستگی بین تیم‌ها را افزایش دهد.

Open Host Service

در این روش، BC ارائه‌دهنده سرویس، مسئولیت ترجمه داده‌ها را بر عهده می‌گیرد و بار ترجمه را از روی گیرنده‌ها برمی‌دارد.

Separate Ways

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

Partnership

در این نوع رابطه، دو BC با هم همکاری می‌کنند تا به یک هدف مشترک برسند. این رابطه معمولاً در Shared Kernel نیز مشاهده می‌شود.

Conformist

در این رابطه، یک BC از BC دیگر تبعیت می‌کند و نیازهای خود را با آن تطبیق می‌دهد.

Upstream/Downstream

در این رابطه، BC پایین‌دست به داده‌ها یا سرویس‌های BC بالادست وابسته است.

Customer-Supplier

در این رابطه، BC تامین‌کننده (Supplier) در تصمیمات خود، نیازهای BC مشتری (Customer) را در نظر می‌گیرد.

Bubble Context

این مفهوم برای کار با سیستم‌های قدیمی (Legacy Systems) استفاده می‌شود. در این روش، یک لایه واسط ایجاد می‌شود که سرویس‌های سیستم قدیمی را به شکل استاندارد و قابل استفاده در اختیار سیستم جدید قرار می‌دهد.

🎯 مثال کاربردی برای درک بهتر مفهوم Bounded Context

برای درک بهتر مفهوم Bounded Context، بیایید یک فروشگاه اینترنتی را در نظر بگیریم که شامل چندین بخش مختلف است. هر کدام از این بخش‌ها می‌توانند به‌عنوان یک Bounded Context مستقل در نظر گرفته شوند، زیرا دارای زبان، مدل و تیم تخصصی خاص خود هستند.

🧾 1. سفارش (Ordering)

در این بخش، کاربر سفارش خود را ثبت می‌کند، آن را پیگیری کرده و ممکن است آن را لغو یا تأیید کند. مفاهیمی مانند «سبد خرید»، «وضعیت سفارش» و «تأیید مشتری» از واژگان کلیدی این بخش هستند. مدل دامنه این بخش صرفاً بر فرآیند سفارش تمرکز دارد.

💳 2. پرداخت (Payment)

در بخش پرداخت، تمرکز روی تراکنش‌های مالی است. اصطلاحاتی مانند «پرداخت موفق»، «کد پیگیری»، و «درگاه پرداخت» در این Bounded Context معنا پیدا می‌کنند. حتی اگر موجودیتی مانند "سفارش" در این بخش نیز استفاده شود، تفسیر آن ممکن است متفاوت با تفسیر موجود در بخش سفارش باشد.

📦 3. انبارداری (Inventory)

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

👩‍💼 4. پشتیبانی مشتریان (Customer Support)

این بخش برای مدیریت ارتباط با مشتریان طراحی شده و شامل مفاهیمی مثل «تیکت پشتیبانی»، «رضایت مشتری» و «پیگیری مشکل» است. این تیم به اطلاعات سفارش یا پرداخت ممکن است نیاز داشته باشد، اما تفسیر و هدف آن‌ها از داده‌ها متفاوت است.

اگرچه همه‌ی این بخش‌ها در حال تعامل با مفاهیم مشترکی مانند "سفارش" یا "کاربر" هستند، اما هرکدام از آن‌ها با دیدگاهی متفاوت به این مفاهیم نگاه می‌کنند.
Bounded Context به ما کمک می‌کند تا مرز بین این دیدگاه‌ها را مشخص کنیم و از درهم‌ریختگی مدل‌های دامنه جلوگیری کنیم.

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

نتیجه‌گیری

شناسایی Core Domain و تعیین Bounded Contextها از مراحل کلیدی در طراحی سیستم‌های نرم‌افزاری بر اساس Domain-Driven Design است. این مفاهیم نه تنها به بهبود معماری سیستم کمک می‌کنند، بلکه با تمرکز بر بخش‌های کلیدی سیستم، ارزش کسب‌وکار را به حداکثر می‌رسانند. استفاده از Context Mapping و الگوهای ارتباطی بین Bounded Contextها نیز به تیم‌ها کمک می‌کند تا سیستم‌های پیچیده را به‌صورت موثرتری مدیریت کنند.

به طور خلاصه، Bounded Context (محدوده‌ی مرزی) به محدوده‌ای از سیستم گفته می‌شود که در آن یک مدل مشخص از دامنه، با زبان مشترک خاص خودش، معنا پیدا می‌کند.
در حالت ایده‌آل، هر Bounded Context با یک Subdomain متناظر است، اما همیشه این‌طور نیست؛ گاهی شرایط سازمان، ساختار تیم یا فناوری باعث می‌شود این تطابق دقیق نباشد.

نکته مهم این است که Bounded Context به فضای "راه‌حل" تعلق دارد، نه صرفاً فضای "مسئله".
برای شناسایی مرز بین Bounded Contextها، می‌توان از فاکتورهایی مثل تفاوت در: