اجازه بدید به مثال کمپانی که قصد فروش محصولات خود را دارد برگردیم. دپارتمان مارکتینگ در این کمپانی در تلاشه که با استفاده از تبلیغات آنلاین بتونه لید تولید کنه. و دپارتمان فروش مسئول اینست که مشتریانی که پتانسیل خرید را دارند را متقاعد کند که محصولات یا خدمات شرکت را خریداری کنند، این زنجیره در شکل زیر نشان داده شده است.
![[3-1.png]]
بررسی زبان متخصصان دامنه نشان می‌دهد که یک مشاهده عجیب و غریب وجود دارد. اصطلاح “لید” معانی مختلفی را در بخش‌های بازاریابی و فروش دارد:
بخش بازاریابی #
برای افراد بازاریابی، یک لید نمایانگر این موضوع هست که اون فرد به یکی از محصولات کمپانی علاقه‌مند است. وقتی یک مشتری به دپارتمان بازاریابی تماس میگیرید و از محصول سوال میپرسد، از نگاه تیم بازاریابی این فرد یک لید هست.
بخش فروش #
در زمینه بخش فروش، یک لید یک موجودیت بسیار پیچیده‌تر است. این نمایانگر کل دوره عمر فرآیند فروش است. این یک رویداد ساده نیست (مثل تماس گرفتن مشتری)، بلکه یک فرآیند طولانی‌مدت است. چگونه می‌توانیم در مورد این شرکت یک زبان فراگیر رو اجرایی کنیم؟
از سویی دیگر، ما می‌دانیم که زبان فراگیر باید پایدار باشد - هر اصطلاح باید یک معنی داشته باشد. و همچنین ما می‌دانیم که زبان فراگیر باید مدل‌های ذهنی متخصصان حوزه را منعکس کند. در این مورد، مدل ذهنی از “لید” در میان متخصصان حوزه‌های فروش و بازاریابی متضاد است.
این ابهام در ارتباطات بین 2 شخص خیلی چالش‌برانگیز نیست. اما این ابهام در ارتباط میان افراد از بخش‌های مختلف ممکن است چالش بیشتری داشته باشد، هر چند برای آدم ها این کار ساده هست که بتونند معنی درست رو در بین تعاملاتشان استنباط کنند.
اما نمایش مدل های متفاوت در حوزه تجاری در نرم‌افزار دشوارتر است. دقت کنید که سورس کد نمیتونه خودش رو با ابهام ها سازگار کنه، پس اگر مدل پیچیده بخش فروش را به بازاریابی بیاریم، ( چون در نگاه لید و معنی کردن و مدل کردن لید، زیر دامنه فروش خیلی پیچیده تر بودش) داریم پیچیدگی را در جایی سوق میدیم که اصلا لزومی برای آن وجود ندارد. پس ما جزییات و رفتار های بسیار بیشتری را داریم تحمیل میکنیم.(از آنچه که افراد بازاریابی برای بهینه سازی کمپین های خود نیاز دارند)
حال اگر سعی کنیم که مدل فروش را بر اساس مدل بازاریابی ساده سازی کنیم، اون وقت با نیازهای زیر حوزه فروش سازگار نیست، و نخواهد بود، زیرا برای مدیریت و بهینه سازی فرایند فروش این زیر سیستم دیگه خیلی سادست. در نتیجه در اولین راه حل ما بیش از حد مهندسی شده داریم به قضیه ورود میکنیم و در دومین حالت یک راه حل بسیار کمتر مهندسی شده را داریم.
خوب چطور این موضوع را حل کنیم؟ راه‌حل سنتی و کلاسیک برای این مشکل طراحی یک مدل واحد است که برای همه‌ی انواع مسائل قابل استفاده باشد. چنین مدل‌هایی باعث ایجاد نمودارهای روابط داده-موجودیت (ERD) عظیمی می‌شوند که اگر این ها رو پرینت کنیم میتواند کل دیوارهای آفیس شمارو بپوشانند. آیا شکل 3-2 یک مدل موثر است؟
![[3-2.png]]
این جور مدل ها همان‌طور که همیشه می‌گن، “همه‌کاره، هیچ‌کاره.” اینگونه مدل‌ها قرار است برای همه چیزی مناسب باشند، اما در نهایت برای هیچ‌چیز مؤثر نیستند. مهم اینه که در این مدل هر چه کار کنید، همیشه با پیچیدگی بیشتری روبه‌رو هستید: فیلتر کردن جزئیات غیرضروری، پیدا کردن آنچه که واقعاً نیاز دارید ، همه ی اینها نمونه هایی از پیچیدگی هستند و بیشتر از همه، پیچیدگی حفظ داده‌ها در یک وضعیت درست و سازگار.
یک راه‌حل دیگر این است که اصطلاحی که ابهام داره ایجاد میکنه ( در اینجا کلمه لید) را با یک کلمه ای از دامنه مربوطه ادغام کنیم: “لید بازاریابی” و “لید فروش”.
این کار درواقع این امکان را فراهم می‌کند که دو مدل را در کد پیاده‌سازی کنیم. با این حال، این رویکرد دو عیب اصلی هم دارد. اول اینکه، بار شناختی را ایجاد می‌کند. هر مدل باید در چه زمانی به کار برده شود؟ هر چه پیاده‌سازی‌های مدل‌های متضاد به یکدیگر نزدیک‌تر باشند، اشتباه کردن آسان‌تر است.
دوم اینکه، پیاده‌سازی مدل با زبان فراگیر هماهنگ نخواهد بود. هیچکس در گفتگوها از پیشوندها استفاده نخواهد کرد.
خوب برای حل چنین مشکلاتی بیاید به الگوهای طراحی مبتنی بر دامنه برگردیم و از اون کمک بگیریم:
bounded context pattern