فصل ۱ — تحلیل دامنههای کسبوکار
اگر شبیه من باشید، احتمالاً عاشق کدنویسی هستید: حل مسائل پیچیده، پیدا کردن راهحلهای ظریف و ساختن دنیاهای کاملاً تازه با طراحی دقیق قوانین، ساختارها و رفتار آنها. به گمانم همین علاقه شما را به طراحی دامنهمحور (Domain-Driven Design یا DDD) کشانده است؛ میخواهید در حرفهتان بهتر شوید. با این حال، این فصل هیچ ارتباطی با نوشتن کد ندارد. در این فصل یاد میگیرید شرکتها چگونه کار میکنند، چرا وجود دارند، چه هدفهایی را دنبال میکنند و برای رسیدن به آن هدفها چه راهبردهایی دارند.
وقتی این مطالب را در کلاسهای DDD تدریس میکنم، بسیاری از دانشجویان واقعاً میپرسند: «لازم است این مطالب را بدانیم؟ ما نرمافزار مینویسیم، نه اینکه کسبوکار اداره کنیم.» پاسخ یک «بله» قاطع است. برای طراحی و ساخت راهکاری مؤثر، باید مسئله را بفهمید. مسئله در زمینهٔ ما همان سامانهٔ نرمافزاری است که باید بسازیم. و برای فهم مسئله باید زمینهای را که مسئله در آن قرار دارد درک کنیم: راهبرد کسبوکار سازمان و ارزشی که سازمان امیدوار است از ساخت نرمافزار به دست آورد.
در این فصل ابزارهای DDD برای تحلیل دامنهٔ کسبوکار یک شرکت و ساختار آن را میآموزید: زیردامنههای هستهای، پشتیبان و عمومی. این مطالب زیربنای طراحی نرمافزار هستند. در فصلهای بعد خواهید دید این مفاهیم چگونه به شکلهای مختلف بر طراحی نرمافزار اثر میگذارند.
دامنهٔ کسبوکار چیست؟
دامنهٔ کسبوکار (Business Domain) حوزهٔ اصلی فعالیت یک شرکت را تعریف میکند. بهطور کلی، همان خدمتی است که شرکت به مشتریانش ارائه میدهد. برای مثال:
- FedEx خدمات ارسال مرسوله ارائه میکند.
- Starbucks بیشتر به خاطر قهوهاش شناخته میشود.
- Walmart یکی از شناختهشدهترین مجموعههای خردهفروشی است.
یک شرکت میتواند در چند دامنهٔ کسبوکار فعالیت کند. برای مثال Amazon هم خدمات خردهفروشی ارائه میکند و هم رایانش ابری. Uber شرکتی در حوزهٔ اشتراک سفر است که خدمات تحویل غذا و اشتراک دوچرخه نیز ارائه میدهد.
نکتهٔ مهم این است که دامنهٔ کسبوکار شرکتها ممکن است بارها تغییر کند. نمونهٔ کلاسیک آن Nokia است که در طول سالها در حوزههایی به متنوعیِ فرآوری چوب، تولید لاستیک، مخابرات و ارتباطات موبایل فعالیت کرده است.
زیردامنه چیست؟
برای رسیدن به اهداف دامنهٔ کسبوکار، شرکت باید در چند زیردامنه (Subdomain) فعالیت کند. زیردامنه حوزهای ریزدانهتر از فعالیت کسبوکار است. همهٔ زیردامنههای شرکت در کنار هم دامنهٔ کسبوکار آن را تشکیل میدهند؛ یعنی همان خدمتی که شرکت به مشتریان ارائه میکند.
پیادهسازی یک زیردامنهٔ منفرد برای موفقیت شرکت کافی نیست؛ آن فقط یک بلوک سازنده در یک سامانهٔ بزرگتر است. زیردامنهها باید با یکدیگر تعامل کنند تا اهداف شرکت در دامنه یا دامنههای کسبوکارش محقق شوند. برای مثال، Starbucks شاید بیش از هر چیز با قهوهاش شناخته شود، اما ساخت یک زنجیرهٔ موفق کافیشاپ فقط به دانستن روش تهیهٔ قهوهٔ خوب محدود نیست. باید املاک را در مکانهای مناسب خرید یا اجاره کرد، نیرو استخدام کرد، امور مالی را مدیریت کرد و فعالیتهای دیگری را انجام داد. هیچیک از این زیردامنهها بهتنهایی شرکت را سودآور نمیکند؛ همهٔ آنها با هم برای رقابت در دامنهٔ کسبوکار ضروریاند.
انواع زیردامنهها
همانطور که یک سامانهٔ نرمافزاری از مؤلفههای معماری گوناگون ـ پایگاه داده، برنامهٔ فرانتاند، سرویس بکاند و غیره ـ تشکیل میشود، زیردامنهها نیز ارزشهای راهبردی و کسبوکاری متفاوتی دارند. DDD سه نوع زیردامنه را متمایز میکند: هستهای (Core)، عمومی (Generic) و پشتیبان (Supporting).
زیردامنههای هستهای
زیردامنهٔ هستهای کاری است که شرکت آن را متفاوت از رقبا انجام میدهد. این تفاوت ممکن است با اختراع محصول یا خدمت جدید شکل بگیرد، یا با کاهش هزینه از طریق بهینهسازی فرایندهای موجود.
Uber را در نظر بگیرید. این شرکت در آغاز شکل تازهای از حملونقل، یعنی اشتراک سفر، ارائه کرد. وقتی رقبا به آن رسیدند، Uber راههایی برای بهینهسازی و تکامل کسبوکار هستهای خود یافت؛ برای نمونه کاهش هزینه از طریق هممسیر کردن مسافرانی که مقصدهای همجهت دارند.
زیردامنههای هستهای Uber مستقیماً بر نتیجهٔ مالی شرکت اثر میگذارند. شرکت از همین راه خود را از رقبا متمایز میکند و خدمات بهتر یا سودآوری بیشتری به دست میآورد. برای حفظ مزیت رقابتی، زیردامنههای هستهای معمولاً شامل اختراعها، بهینهسازیهای هوشمند، دانش تخصصی کسبوکار یا دیگر انواع مالکیت فکریاند.
نمونهٔ دیگر الگوریتم رتبهبندی Google Search است. در زمان نگارش کتاب، سکوی تبلیغاتی Google بخش عمدهٔ سود شرکت را ایجاد میکند. البته Google Ads خود یک زیردامنه نیست، بلکه دامنهٔ کسبوکاری جداگانه با زیردامنههای خودش است؛ همانطور که Google Cloud Platform، Google Workspaces و دیگر حوزههای فعالیت Alphabet نیز دامنههای دیگری هستند. اما Google Search و الگوریتم رتبهبندی آن چه؟ هرچند موتور جستوجو خدمت پولی نیست، بزرگترین سکوی نمایش Google Ads است. توانایی ارائهٔ نتایج جستوجوی عالی باعث جذب ترافیک میشود و در نتیجه جزء مهمی از کسبوکار تبلیغات است. اگر یک خطا نتایج ضعیف ایجاد کند یا رقیبی جستوجوی بهتری ارائه دهد، درآمد تبلیغات آسیب میبیند. بنابراین الگوریتم رتبهبندی برای Google زیردامنهای هستهای است.
پیچیدگی
زیردامنهٔ هستهای که پیادهسازیاش ساده باشد فقط میتواند مزیت رقابتی کوتاهمدتی بسازد؛ رقبا سریع به آن میرسند. بنابراین زیردامنههای هستهای ذاتاً پیچیدهاند. Uber با اشتراک سفر نهتنها بازار تازهای ایجاد کرد، بلکه معماری یکپارچه و چنددهسالهٔ صنعت تاکسی را با استفادهٔ هدفمند از فناوری برهم زد. Uber با فهم دامنهٔ کسبوکار توانست روش حملونقلی قابلاعتمادتر و شفافتر طراحی کند. باید برای ورود به کسبوکار هستهای شرکت موانع بالایی وجود داشته باشد و کپی کردن راهکار شرکت برای رقبا دشوار باشد.
منابع مزیت رقابتی
زیردامنههای هستهای الزاماً فنی نیستند. همهٔ مسائل کسبوکار با الگوریتم یا راهکار فنی حل نمیشوند و مزیت رقابتی میتواند از منابع مختلفی ایجاد شود.
مثلاً یک طراح جواهر را در نظر بگیرید که محصولاتش را آنلاین میفروشد. فروشگاه آنلاین مهم است، اما زیردامنهٔ هستهای نیست؛ طراحی جواهر هستهای است. شرکت میتواند موتور فروشگاه آماده بخرد یا بهکار گیرد، اما نمیتواند طراحی جواهر خود را برونسپاری کند. همین طراحی دلیل خرید مشتریان و به خاطر سپردن برند است.
نمونهای پیچیدهتر: شرکتی را تصور کنید که در کشف دستی تقلب تخصص دارد. شرکت تحلیلگرانش را آموزش میدهد اسناد مشکوک را بررسی و موارد احتمالی تقلب را علامتگذاری کنند. شما سامانهای میسازید که تحلیلگران با آن کار میکنند. آیا سامانه زیردامنهٔ هستهای است؟ خیر. زیردامنهٔ هستهای همان کاری است که تحلیلگران انجام میدهند. نرمافزار شما تقلب را تحلیل نمیکند؛ فقط اسناد را نمایش میدهد و نظرهای تحلیلگران را ثبت میکند.
زیردامنهٔ هستهای در برابر Core Domain
زیردامنههای هستهای را Core Domain نیز مینامند. Eric Evans در کتاب اصلی DDD دو اصطلاح Core Subdomain و Core Domain را بهجای هم استفاده میکند. نویسنده ترجیح میدهد «Core Subdomain» بگوید: اول اینکه واقعاً یک زیردامنه است و نباید با Business Domain اشتباه شود؛ دوم اینکه، همانطور که در فصل ۱۱ میبینیم، نوع زیردامنهها میتواند در طول زمان تغییر کند. مثلاً یک زیردامنهٔ هستهای ممکن است عمومی شود. گفتن «زیردامنهٔ عمومی به زیردامنهٔ هستهای تبدیل شد» روشنتر از آن است که بگوییم «زیردامنهٔ عمومی به Core Domain تبدیل شد».
زیردامنههای عمومی
زیردامنهٔ عمومی (Generic Subdomain) فعالیتی کسبوکاری است که همهٔ شرکتها تقریباً به یک شکل انجام میدهند. این زیردامنهها، مانند زیردامنههای هستهای، معمولاً پیچیده و دشوارند، اما هیچ مزیت رقابتی خاصی ایجاد نمیکنند. نیازی به نوآوری یا بهینهسازی اختصاصی نیست؛ راهکارهای آزمودهشده در دسترساند و شرکتهای مختلف از آنها استفاده میکنند.
برای مثال، بیشتر سامانهها باید کاربران را احراز هویت و مجاز کنند. بهجای اختراع سازوکار اختصاصی احراز هویت، منطقیتر است از راهکار موجود استفاده شود. چنین راهکاری معمولاً قابلاعتمادتر و امنتر است، زیرا شرکتهای فراوانی با نیاز مشابه آن را آزمودهاند.
در مثال جواهرفروش آنلاین، طراحی جواهر زیردامنهٔ هستهای است، اما فروشگاه آنلاین زیردامنهای عمومی است. استفاده از همان سکوی خردهفروشی آنلاین که رقبا استفاده میکنند، مزیت رقابتی جواهرفروش را از بین نمیبرد.
زیردامنههای پشتیبان
همانطور که از نامشان پیداست، زیردامنههای پشتیبان (Supporting Subdomains) از کسبوکار شرکت پشتیبانی میکنند، اما برخلاف زیردامنههای هستهای مزیت رقابتی ایجاد نمیکنند.
مثلاً یک شرکت تبلیغات آنلاین را در نظر بگیرید که زیردامنههای هستهای آن شامل تطبیق آگهی با بازدیدکننده، بهینهسازی اثربخشی آگهی و کمینه کردن هزینهٔ فضای تبلیغاتی است. برای موفقیت در این حوزهها شرکت باید مواد خلاقهٔ خود را فهرست و دستهبندی کند. روش ذخیره و نمایهسازی اقلامی مانند بنرها و Landing Pageها مستقیماً بر سود شرکت اثر ندارد و چیزی برای اختراع یا بهینهسازی راهبردی در آن نیست. با این حال، کاتالوگ محتوای خلاقه برای سامانههای مدیریت و ارائهٔ تبلیغات ضروری است؛ بنابراین راهکار کاتالوگ محتوا یک زیردامنهٔ پشتیبان است.
ویژگی متمایز زیردامنههای پشتیبان سادگی منطق کسبوکار است. منطق آنها بیشتر شبیه فرمهای ورود داده و عملیات ETL (Extract, Transform, Load) است؛ یعنی همان رابطهای CRUD (Create, Read, Update, Delete). این حوزهها مزیت رقابتی ایجاد نمیکنند و بنابراین به موانع ورود بالا نیاز ندارند.
مقایسهٔ زیردامنهها
مزیت رقابتی
فقط زیردامنههای هستهای به شرکت مزیت رقابتی میدهند؛ آنها بخشی از راهبرد شرکت برای متمایز شدن از رقبا هستند. زیردامنههای عمومی بنا بر تعریف نمیتوانند منبع مزیت باشند، زیرا راهکارهایی عمومی و مشترک با رقبا هستند. زیردامنههای پشتیبان نیز موانع ورود پایینی دارند و مزیت رقابتی ایجاد نمیکنند.
شرکت معمولاً مشکلی ندارد که رقیب زیردامنهٔ پشتیبانش را کپی کند، زیرا رقابتپذیریاش تغییر نمیکند. از نظر راهبردی حتی ترجیح میدهد زیردامنههای پشتیبان به راهکارهای عمومی و آماده تبدیل شوند تا نیاز به طراحی و ساخت اختصاصی حذف شود. فصل ۱۱ تبدیل Supporting به Generic و تغییرات دیگر را بررسی میکند و ضمیمه A نمونهای واقعی ارائه میدهد.
هرچه مسائل پیچیدهتری را شرکت بتواند حل کند، ارزش کسبوکاری بیشتری میتواند ایجاد کند. مسئلهٔ پیچیده فقط ارائهٔ خدمت به مشتری نیست؛ بهینهتر و کارآمدتر کردن خود کسبوکار هم میتواند مسئلهای پیچیده باشد. ارائهٔ سطح مشابه خدمت با هزینهٔ عملیاتی کمتر از رقبا نیز مزیت رقابتی است.
پیچیدگی
از دید فنی، شناسایی زیردامنهها مهم است، زیرا انواع مختلف سطح پیچیدگی متفاوتی دارند. هنگام طراحی نرمافزار باید ابزارها و تکنیکهایی انتخاب کنیم که با پیچیدگی نیازمندیهای کسبوکار متناسب باشند؛ پس شناسایی زیردامنهها برای طراحی راهکاری سالم ضروری است.
منطق کسبوکار زیردامنهٔ پشتیبان ساده است: عملیات پایهٔ ETL و رابطهای CRUD، معمولاً محدود به اعتبارسنجی ورودی یا تبدیل داده از یک ساختار به ساختاری دیگر.
زیردامنهٔ عمومی بسیار پیچیدهتر است. حتماً دلیلی وجود دارد که دیگران قبلاً زمان و تلاش زیادی برای حل آن صرف کردهاند. مثالهای روشن آن الگوریتمهای رمزنگاری یا سازوکارهای احراز هویتاند. از منظر دسترسی به دانش، این زیردامنهها «ناشناختههای شناختهشده» هستند؛ میدانید چه چیزی را نمیدانید، و دانش لازم نیز در دسترس است. میتوانید از بهترین شیوههای صنعت استفاده کنید یا در صورت نیاز مشاوری متخصص بهکار بگیرید.
زیردامنههای هستهای پیچیدهاند و باید تا حد ممکن کپی کردن آنها برای رقبا دشوار باشد، چون سودآوری شرکت به آنها وابسته است. بنابراین شرکتها از نظر راهبردی به دنبال حل مسائل پیچیده در زیردامنههای هستهایاند.
گاهی تمایز هستهای و پشتیبان دشوار است. پیچیدگی میتواند راهنما باشد: آیا زیردامنه میتواند به کسبوکاری جانبی تبدیل شود؟ آیا کسی حاضر است برای خود آن پول بدهد؟ اگر بله، احتمالاً هستهای است. برای تمایز پشتیبان و عمومی نیز بپرسید: آیا ساخت یک پیادهسازی سادهٔ داخلی ارزانتر و آسانتر از یکپارچه کردن راهکار خارجی است؟ اگر بله، احتمالاً زیردامنه پشتیبان است.
برای تشخیص زیردامنهٔ هستهای مرتبط با نرمافزار، پیچیدگی منطق کسبوکاری را که باید در کد مدل و پیادهسازی شود بررسی کنید. آیا منطق شبیه فرم CRUD برای ورود داده است، یا باید الگوریتمهای پیچیده یا فرایندهایی را پیاده کنید که با قواعد و Invariantهای پیچیده هدایت میشوند؟ حالت اول نشانهٔ زیردامنهٔ پشتیبان و حالت دوم نمونهٔ متداول زیردامنهٔ هستهای است.
شکل 1-1 رابطهٔ سه نوع زیردامنه را بر اساس تمایز کسبوکاری و پیچیدگی منطق کسبوکار نمایش میدهد. محدودهٔ بین Supporting و Generic خاکستری است: اگر برای کارکرد یک زیردامنهٔ پشتیبان راهکار عمومی وجود داشته باشد، نوع نهایی بستگی دارد به اینکه یکپارچه کردن راهکار عمومی سادهتر/ارزانتر از ساخت آن از ابتدا باشد یا نه.
نوسان و تغییرپذیری
همانطور که گفته شد، زیردامنههای هستهای ممکن است مرتب تغییر کنند. اگر مسئلهای در اولین تلاش حل شود احتمالاً مزیت رقابتی خوبی نیست، چون رقبا سریع به آن میرسند. بنابراین راهکارهای هستهای ماهیتی تکاملی دارند: پیادهسازیهای مختلف امتحان، پالایش و بهینه میشوند. کار روی زیردامنهٔ هستهای هیچگاه واقعاً تمام نمیشود؛ شرکتها دائماً آن را با قابلیتهای تازه یا بهینهسازی کارکرد موجود توسعه میدهند. این تکامل پیوسته برای جلو ماندن از رقبا ضروری است.
برخلاف هستهایها، زیردامنههای پشتیبان زیاد تغییر نمیکنند، چون مزیت رقابتی ایجاد نمیکنند و سرمایهگذاری روی تکامل آنها در مقایسه با هستهایها ارزش کسبوکاری کمی دارد. زیردامنههای عمومی با وجود راهکارهای موجود میتوانند تغییر کنند؛ مثلاً در قالب وصلهٔ امنیتی، رفع اشکال یا راهکار کاملاً تازه برای مسئلهٔ عمومی.
راهبرد راهحل
زیردامنههای هستهای توان رقابت شرکت را میسازند. این مسئولیتی حیاتی است، اما به این معنا نیست که زیردامنههای عمومی و پشتیبان مهم نیستند؛ همهٔ زیردامنهها برای فعالیت شرکت لازماند و حذف یکی ممکن است کل ساختار را فرو بریزد. با این حال میتوان ویژگیهای ذاتی هر نوع را برای انتخاب کارآمدترین راهبرد پیادهسازی بهکار گرفت.
زیردامنهٔ هستهای باید درون سازمان پیاده شود. نمیتوان آن را خرید یا مستقیماً بهکار گرفت، زیرا در این صورت رقبا هم همان امکان را دارند و مفهوم مزیت رقابتی تضعیف میشود. برونسپاری پیادهسازی هستهای نیز تصمیم خوبی نیست؛ این یک سرمایهگذاری راهبردی است. میانبُر زدن در کوتاهمدت ریسک دارد و در بلندمدت میتواند پیامدهای مرگبار داشته باشد، مثل کدبیس غیرقابلنگهداری که دیگر اهداف شرکت را پشتیبانی نمیکند.
ماهرترین نیروهای سازمان باید روی زیردامنههای هستهای کار کنند. پیادهسازی داخلی امکان تغییر و تکامل سریعتر و ساخت مزیت رقابتی در زمان کمتر را فراهم میکند. چون نیازمندیهای هستهای پیوسته تغییر میکنند، راهکار باید قابلنگهداری و تکاملپذیر باشد و پیشرفتهترین تکنیکهای مهندسی را بهکار گیرد.
زیردامنههای عمومی مسائل دشوار اما حلشدهاند؛ بنابراین خرید محصول آماده یا استفاده از راهکار متنباز معمولاً بهصرفهتر از پیادهسازی داخلی است.
برای زیردامنههای پشتیبان، نبود مزیت رقابتی باعث میشود اجتناب از سرمایهگذاری سنگین منطقی باشد، اما برخلاف Generic همیشه راهکار آمادهای وجود ندارد و ممکن است شرکت مجبور شود خودش آنها را بسازد. سادگی منطق و تغییرات کم اجازه میدهد طراحی سادهتری انتخاب شود. چارچوب Rapid Application Development معمولاً کافی است و نیازی به الگوهای طراحی پیچیده نیست.
از منظر نیروی انسانی، زیردامنهٔ پشتیبان به بالاترین سطح مهارت فنی نیاز ندارد و فرصت مناسبی برای آموزش نیروهای تازهکار است. مهندسان باتجربه در حل مسائل پیچیده را برای زیردامنههای هستهای نگه دارید. سادگی منطق کسبوکار همچنین زیردامنههای پشتیبان را گزینهٔ مناسبی برای برونسپاری میکند.
جدول 1-1 — تفاوت سه نوع زیردامنه| نوع زیردامنه | مزیت رقابتی | پیچیدگی | تغییرپذیری | پیادهسازی | نوع مسئله |
|---|
| هستهای | بله | زیاد | زیاد | داخل سازمان | جالب/چالشبرانگیز |
| عمومی | خیر | زیاد | کم | خرید/بهکارگیری | حلشده |
| پشتیبان | خیر | کم | کم | داخل سازمان/برونسپاری | واضح |
شناسایی مرزهای زیردامنه
شناسایی زیردامنهها و نوع آنها میتواند در تصمیمهای طراحی نرمافزار بسیار کمککننده باشد. زیردامنهها توسط راهبرد کسبوکار شرکت، دامنههای فعالیت و نحوهٔ تمایز آن از رقبا تعریف میشوند. در بیشتر پروژهها زیردامنهها به نوعی از قبل «وجود دارند»، اما پیدا کردن مرز دقیقشان همیشه آسان نیست. اگر از مدیرعامل بخواهید فهرست زیردامنههای شرکت را بدهد احتمالاً با نگاه خالی روبهرو میشوید؛ این اصطلاح برای او الزاماً شناختهشده نیست. بنابراین باید تحلیل دامنه انجام دهید و زیردامنهها را شناسایی و دستهبندی کنید.
نقطهٔ شروع مناسب، واحدها و بخشهای سازمانی شرکت است. یک فروشگاه آنلاین ممکن است انبار، خدمات مشتریان، جمعآوری سفارش، ارسال، کنترل کیفیت و مدیریت کانال داشته باشد. اما اینها حوزههای نسبتاً درشتدانهاند. مثلاً خدمات مشتریان را شاید پشتیبان یا حتی عمومی بدانیم، چون اغلب برونسپاری میشود. آیا همین اطلاعات برای تصمیم طراحی کافی است؟
تقطیر زیردامنهها
زیردامنههای درشتدانه نقطهٔ شروع خوبیاند، اما جزئیات مهماند و نباید اطلاعاتی را که در پیچیدگیهای یک کارکرد کسبوکار پنهان شده از دست بدهیم.
اگر داخل بخش خدمات مشتریان را بررسی کنیم، میبینیم معمولاً از اجزای ریزتری مانند سامانهٔ Help Desk، مدیریت و زمانبندی شیفت، سامانهٔ تلفنی و غیره تشکیل شده است. هرکدام ممکن است نوع متفاوتی داشته باشند: Help Desk و تلفن عمومیاند، مدیریت شیفت پشتیبان است، و شرکت ممکن است الگوریتم هوشمند اختصاصی برای مسیریابی رخدادها به عاملانی بسازد که در گذشته در موارد مشابه موفق بودهاند. تحلیل پروندههای ورودی و یافتن شباهت با تجربهٔ گذشته کار سادهای نیست. چون این الگوریتم تجربهٔ مشتری را نسبت به رقبا بهتر میکند، زیردامنهای هستهای است. شکل 1-2 همین تحلیل را نشان میدهد.
با این حال نمیتوان بینهایت به سطوح ریزتر رفت. کجا باید متوقف شد؟
زیردامنهها بهعنوان Use Caseهای منسجم
از دید فنی، زیردامنهها شبیه مجموعهای از Use Caseهای مرتبط و منسجم هستند. چنین مجموعهای معمولاً بازیگر یکسانی دارد، روی موجودیتهای کسبوکاری مرتبط کار میکند و مجموعهای نزدیک از دادهها را دستکاری میکند.
نمودار Use Case درگاه پرداخت کارت اعتباری در شکل 1-3 را در نظر بگیرید. Use Caseها از طریق دادههای مشترک و بازیگران دخیل بهشدت به هم متصلاند؛ بنابراین همه با هم زیردامنهٔ پرداخت کارت اعتباری را تشکیل میدهند. تعریف «زیردامنه بهعنوان مجموعهای از Use Caseهای منسجم» میتواند راهنمای توقف در ریزکردن مرزها باشد؛ این دقیقترین مرز قابلاستفادهٔ زیردامنه است.
آیا باید همیشه مرزها را تا این حد دقیق کرد؟ برای زیردامنههای هستهای بله. آنها مهمترین، متغیرترین و پیچیدهترین بخشاند و باید تا حد امکان تقطیر شوند تا همهٔ کارکردهای عمومی و پشتیبان از آنها جدا شود و سرمایهگذاری فقط بر کارکرد متمرکز هستهای انجام گیرد.
برای زیردامنههای پشتیبان و عمومی میتوان سختگیری را کمتر کرد. اگر ریزتر شدن هیچ بینش تازهای برای تصمیم طراحی ایجاد نمیکند، همانجا میتوان متوقف شد. مثلاً اگر تمام اجزای ریزتر همان نوع زیردامنهٔ اصلی باشند، ارزش راهبردی جدیدی کشف نمیشود. شکل 1-4 نشان میدهد ریزکردن بیشتر Help Desk چند جزء عمومی را آشکار میکند اما اطلاعات راهبردی جدیدی نمیدهد؛ در نهایت یک ابزار آمادهٔ درشتدانه استفاده خواهد شد.
تمرکز بر موارد ضروری
زیردامنهها ابزاری برای آسانتر کردن تصمیمهای طراحی نرمافزار هستند. هر سازمان احتمالاً کارکردهای کسبوکاری زیادی دارد که مزیت رقابتی میسازند اما هیچ ارتباطی با نرمافزار ندارند؛ مثال طراحی جواهر یکی از آنها بود. هنگام شناسایی زیردامنهها باید کارکردهای غیرنرمافزاری را تشخیص داد، آنها را بهعنوان چنین مواردی پذیرفت و روی جنبههایی تمرکز کرد که به سامانهٔ نرمافزاری موردنظر مربوطاند.
نمونههای تحلیل دامنه
اکنون میبینیم چگونه مفهوم زیردامنه در عمل به تصمیمهای راهبردی طراحی کمک میکند. دو شرکت خیالی Gigmaster و BusVNext بررسی میشوند. هنگام خواندن، دامنهٔ کسبوکارشان را تحلیل و سه نوع زیردامنه را پیدا کنید. مانند دنیای واقعی، برخی نیازمندیها ضمنی هستند.
تذکر: طبیعتاً از یک توضیح کوتاه نمیتوان تمام زیردامنههای هر کسبوکار را شناسایی کرد، اما همین اطلاعات برای تمرین تشخیص و دستهبندی زیردامنهها کافی است.
Gigmaster
Gigmaster شرکت فروش و توزیع بلیت است. برنامهٔ موبایل آن کتابخانهٔ موسیقی کاربران، حسابهای سرویسهای استریم و پروفایلهای شبکههای اجتماعی را تحلیل میکند تا اجراهای نزدیک و مورد علاقهٔ هر کاربر را پیشنهاد دهد.
کاربران Gigmaster نسبت به حریم خصوصی حساساند؛ بنابراین تمام اطلاعات شخصی رمزنگاری میشود. همچنین برای اینکه علاقههای خصوصی کاربران تحت هیچ شرایطی افشا نشود، الگوریتم پیشنهاد فقط با دادهٔ ناشناسشده کار میکند.
برای بهبود پیشنهادها ماژول تازهای ساخته شده است که به کاربران اجازه میدهد اجراهایی را که در گذشته حضور داشتهاند ثبت کنند، حتی اگر بلیت از Gigmaster خریداری نشده باشد.
دامنه و زیردامنهها
دامنهٔ کسبوکار Gigmaster فروش بلیت است.
هستهای: موتور پیشنهاد، ناشناسسازی داده و برنامهٔ موبایل. موتور پیشنهاد مزیت اصلی است، حفظ حریم خصوصی اهمیت راهبردی دارد و میتوان استنباط کرد تجربهٔ کاربری موبایل نیز حیاتی است.
عمومی: رمزنگاری داده، حسابداری، تسویه/دریافت وجه و احراز هویت/مجوزدهی.
پشتیبان: یکپارچهسازی با سرویسهای استریم موسیقی، یکپارچهسازی با شبکههای اجتماعی و ماژول اجراهای شرکتکرده؛ منطق اینها ساده و شبیه ETL یا CRUD است.
تصمیمهای طراحی
- موتور پیشنهاد، ناشناسسازی داده و برنامهٔ موبایل باید داخل سازمان و با پیشرفتهترین ابزارها و تکنیکهای مهندسی ساخته شوند؛ اینها بیشترین تغییر را خواهند داشت.
- برای رمزنگاری، حسابداری، تسویه و احراز هویت از راهکار آماده یا متنباز استفاده شود.
- یکپارچهسازی با سرویسهای استریم و شبکههای اجتماعی و ماژول اجراهای قبلی میتواند برونسپاری شود.
BusVNext
BusVNext شرکت حملونقل عمومی است که میخواهد سفر با اتوبوس را به اندازهٔ گرفتن تاکسی راحت کند و ناوگان اتوبوس در شهرهای بزرگ را مدیریت میکند.
مشتری میتواند با برنامهٔ موبایل سفر سفارش دهد. در زمان تعیینشده، مسیر یک اتوبوس نزدیک بهصورت پویا تغییر میکند تا مشتری را در محل و زمان مشخص سوار کند.
بزرگترین چالش شرکت پیادهسازی الگوریتم مسیریابی بود؛ مسئله گونهای از «مسئلهٔ فروشندهٔ دورهگرد» (Travelling Salesman Problem) است. منطق مسیریابی پیوسته تنظیم و بهینه میشود. آمار نشان داد دلیل اصلی لغو سفر، انتظار طولانی برای رسیدن اتوبوس است؛ بنابراین الگوریتم طوری تغییر کرد که سوار کردن سریع را در اولویت بگذارد، حتی اگر پیاده کردن دیرتر شود. برای بهینهسازی بیشتر، BusVNext با ارائهدهندگان ثالث اطلاعات ترافیک و هشدارهای لحظهای یکپارچه میشود.
BusVNext گاهی برای جذب مشتری جدید و متعادل کردن تقاضا در ساعات اوج و کمتقاضا تخفیفهای ویژه ارائه میکند.
دامنه و زیردامنهها
خدمت BusVNext سفر بهینهشده با اتوبوس و دامنهٔ کسبوکار آن حملونقل عمومی است.
هستهای: مسیریابی، تحلیل داده، تجربهٔ کاربری برنامهٔ موبایل و مدیریت ناوگان. الگوریتم مسیریابی مسئلهای پیچیده را با توجه به اهداف مختلف کسبوکار حل میکند؛ دادهٔ سفر برای کشف رفتار مشتری تحلیل میشود؛ برنامههای مشتری و راننده باید بسیار قابلاستفاده باشند؛ و مدیریت ناوگان نیز به دلیل خرابی و نگهداری اتوبوسها مسئلهای غیرساده و اثرگذار بر درآمد و سطح خدمت است.
عمومی: شرایط ترافیک، حسابداری، Billing و Authorization.
پشتیبان: مدیریت پروموشنها و تخفیفها؛ رابط مدیریت آن شبیه CRUD ساده برای کدهای کوپن فعال است.
تصمیمهای طراحی
- الگوریتم مسیریابی، تحلیل داده، مدیریت ناوگان و قابلیت استفادهٔ برنامه باید داخل سازمان و با ابزارها و الگوهای فنی پیشرفته ساخته شوند.
- پیادهسازی ماژول مدیریت تخفیف میتواند برونسپاری شود.
- تشخیص وضعیت ترافیک، احراز و مجوزدهی کاربران و مدیریت سوابق و تراکنشهای مالی میتواند به ارائهدهندگان بیرونی سپرده شود.
متخصصان دامنه چه کسانی هستند؟
اکنون که دامنهها و زیردامنهها روشن شدند، اصطلاح مهم دیگر DDD را معرفی میکنیم: متخصصان دامنه (Domain Experts). متخصص دامنه همان Subject Matter Expert است که ظرافتهای کسبوکاری را که قرار است در کد مدل و پیادهسازی شود میشناسد؛ مرجع دانش در دامنهٔ کسبوکار نرمافزار.
متخصصان دامنه نه تحلیلگرانی هستند که نیازمندیها را جمعآوری میکنند و نه مهندسانی که سامانه را طراحی میکنند. آنها نمایندهٔ کسبوکارند؛ کسانی که مسئلهٔ کسبوکار را در اصل شناسایی کردهاند و دانش کسبوکار از آنها منشأ میگیرد. تحلیلگران سامانه و مهندسان مدل ذهنی آنها از دامنه را به نیازمندیهای نرمافزار و کد منبع تبدیل میکنند.
بهعنوان قاعدهٔ سرانگشتی، متخصصان دامنه یا کسانی هستند که نیازمندیها را تعیین میکنند یا کاربران نهایی نرمافزارند؛ نرمافزار قرار است مسائل آنها را حل کند. دامنهٔ تخصص هر متخصص میتواند متفاوت باشد: برخی کل دامنهٔ کسبوکار را عمیق میشناسند و برخی در زیردامنهای خاص تخصص دارند. در یک آژانس تبلیغات آنلاین، مدیران کمپین، خریداران رسانه، تحلیلگران و دیگر ذینفعان کسبوکار نمونهٔ متخصصان دامنهاند.
نتیجهگیری
در این فصل ابزارهای DDD برای فهم فعالیت کسبوکاری شرکت بررسی شد. همهچیز از دامنهٔ کسبوکار آغاز میشود: حوزهای که شرکت در آن فعالیت میکند و خدمتی که به مشتریان میدهد.
همچنین بلوکهایی را شناختید که برای موفقیت در دامنه و تمایز از رقبا لازماند:
- زیردامنههای هستهای: مسائل جالب؛ فعالیتهایی که شرکت متفاوت از رقبا انجام میدهد و از آنها مزیت رقابتی میگیرد.
- زیردامنههای عمومی: مسائل حلشده؛ چیزهایی که همهٔ شرکتها تقریباً یکسان انجام میدهند. فضای نوآوری خاصی وجود ندارد و استفاده از راهکار موجود مقرونبهصرفهتر است.
- زیردامنههای پشتیبان: مسائلی با راهحل روشن؛ فعالیتهایی که شرکت احتمالاً باید خودش یا با برونسپاری پیاده کند اما مزیت رقابتی ایجاد نمیکنند.
در پایان دیدیم متخصصان دامنه کارشناسان موضوعی کسبوکارند که دانش عمیقی از دامنه یا یک یا چند زیردامنه دارند و برای موفقیت پروژه حیاتیاند.
تمرینها
- کدام زیردامنه یا زیردامنهها هیچ مزیت رقابتی ایجاد نمیکنند؟
- هستهای
- عمومی
- پشتیبان
- B و C
- برای کدام زیردامنه ممکن است همهٔ رقبا از راهکار یکسان استفاده کنند؟
- هستهای
- عمومی
- پشتیبان
- هیچکدام؛ شرکت باید همیشه خود را از رقبا متمایز کند.
- کدام نوع زیردامنه انتظار میرود بیشترین تغییر را داشته باشد؟
- هستهای
- عمومی
- پشتیبان
- تفاوتی در تغییرپذیری انواع زیردامنه وجود ندارد.
با توجه به توضیح WolfDesk در مقدمهٔ نویسنده:
- دامنهٔ کسبوکار WolfDesk چیست؟
- زیردامنه یا زیردامنههای هستهای WolfDesk کداماند؟
- زیردامنه یا زیردامنههای پشتیبان WolfDesk کداماند؟
- زیردامنه یا زیردامنههای عمومی WolfDesk کداماند؟