قسمت اول سری «مایکروسرویس و DDD برای تیمهای کوچیک؟»
قسمت اول سری «مایکروسرویس و DDD برای تیمهای کوچیک؟»
✅ خواستگاه و قصهی شکلگیری
بعد از مقدمهای که هدفش طرح مسئله بود، این بار میخوام قبل از اینکه به سوال «چهکار کنیم؟» بپردازیم، در مورد «اینها از کجا اومدند؟» فکر کنیم. شاید پاسخ همین سوال که خواستگاه و مسئلهای که اینها براش به وجود اومدن، برای تصمیمگیری عدهای راهگشا باشه. من به برخی نیازها و خصوصیاتشون اشاره میکنم؛ و تصمیم با خواننده خواهد بود که آیا اساسا «مسئلهای که چنین پاسخهایی براش ایجاد شده» در سازمان و تیم و محصولش وجود داره یا نه؟
🎂 الف: DDD از کجا و از دل چه نیازی بیرون اومد؟
خالق: اریک ایوانز (Eric Evans)
سال انتشار: ۲۰۰۴
محیط پیدایش: شرکتهای بزرگ مشاورهای و enterprise.
اریک ایوانز از اوایل دهه ۹۰ میلادی روی پروژههای متعدد نرمافزاری و عموما مرتبط با شرکتهای «large enterprise» کار میکرده، و وقتی کتاب معروف "Domain-Driven Design: Tackling Complexity in the Heart of Software" رو در سال ۲۰۰۴ منتشر میکنه، عملا ماحصل یک دهه تجربهی کار روی سیستمهای پیچیده enterprise رو در قالب یک روش ساختاریافته معرفی کرد. سابقهی کار توی شرکتهایی که مسائل پیچیده بیزنسی دارن و نیازمند درک عمیق domain دارن رو کسب کرده بوده؛ و با تیمهای بزرگ (معمولاً +۲۰ نفر) که روی پروژههای چندساله کار میکردن رو داشته (خصوصیت مشترک چنین سازمانهایی).
توی این تیپ سازمانها هر domain، فرد یا افراد متخصص خودش رو داره که باید زیر و بم دامنه رو بدونن؛ و ارتباط بین دامنهای از طریق اون افراد ضروریه. اغلب هم Legacy systems دارن و باید با اونا integration انجام بشه.
مسئلهی اصلی: پیچیدگی دامنههای کسبوکار (قوانین متغیر، اصطلاحات تخصصی، استثناهای ریز و درشت، چندین سابدامین با رفتارهای متفاوت).
پاسخِ DDD: نزدیککردن مدل نرمافزار به زبان و منطق دامنه؛ با مفاهیمی مثل:
مفهوم Ubiquitous Language: یعنی اینکه تیم فنی و بیزنس، و به تبعش توی محصول و مستندات، برای یک مفهوم خاص، فقط یک ترم مشترک استفاده بشه. توی سیستمهای بزرگ و پیچیده، صدها و گاها چند هزار عبارت و مخفف استفاده میشه که اگر به سمت زبان مشترک نریم، توسعهدهنده یه جا یه مخفف رو میشنوه، یه جا ترم کامل، و یه جا یک کلمه از ترم رو؛ تا اینجا باعث گیج شدنش میشه، ولی مشکل بزرگتر وقتیه که ترمهای مشابه وجود داره و هر دامنه به فراخور میزان کاربرد، منظورش از یه ترم متفاوته و به یه چیز خاص اشاره میکنه. مثلا تعریفش از «هزینه» یه چیزیه که توسعه دهنده دامنه دیگه به یه چیز دیگه میگه «هزینه» (انواع مختلفی از هزینه مثل ثابت، متغیر، نیمه متغیر، مستقیم، توزیع و... بسته وجود داره)؛ و این عدم استفاده از یک زبان مشترک توی سازمانهای بزرگ، میتونه منجر به سردرگمی و اشتباهات محاسباتی و... بشه.
مفهوم Bounded Context میگه باید مرزبندی شفاف برای مدلها و معانی داشت؛ هر کانتکست فرهنگ خودش رو داره و باید دقیقا مشخص باشه کدوم قابلیت مربوط به کدوم دامنه میشه. توی سیستمهای خیلی بزرگ، خیلی وقتها باید چند جلسه با متخصصین دو تا دامنه بشینیم که بتونیم تصمیم بگیریم آیا این قابلیت توی کدوم دامنه قرار بگیره بهتره. (با نگاه پیادهسازی و همچنین آینده محصول).
بارها پیش میاد که توی سازمان بزرگ باید بگردی توی مستندات یا از افراد مختلف، که متخصص فلان دامنه کیه، چون حتی نمیشناسیش!
مفهوم Context Mapping، یعنی نقشهی ارتباط بین bounded contextsها، که ارتباط بین کانتکستها رو هم از منظر روابط تیمها تبیین میکنه هم از نظر الگوهای ارتباطی. به بیان ساده، اینقدر داستان بزرگ و پیچیده هست که نیازه تا برای ارتباط بین تیمهای متعدد، که گاها به چند ده، یا حتی چند صد تیم میرسه، بیان بگن انواع ارتباطات بین کانتکستها و تیمها در چه قالبهایی میگنجه.
اینها توصیف مختصری از خواستگاه و بافتار پیدایشی DDD بود که توسط برخی از جواگره حتی گاها با domain-centric جابجا بیان میشه!
حالا کجا این مفاهیم شکوفا شده؟ پاسخ: سازمانهای عمدتا بزرگ و بعدتر متوسط (در مقیاس جهانی)، چرا تعریف مقیاس و سایز مهمه؟ چون گاهی ما به یه شرکت ۳۰۰ نفره میگیم بزرگ!! که واقعا بزرگ محسوب نمیشه. یا گاهی یک سازمان ۱۱ هزار نفره رو بزرگ میدونیم، درحایلکه ساختارش از نظر بلوغ، شبیه یک شرکت ۵۰ نفره است (مثال و تجربه عینی توی ذهنمه 😁). در چنین فضاهایی، DDD هزینهی هماهنگی رو کم، و سرعت تغییرِ درست رو زیاد میکنه خصوصا که چرخهی عمر بلندمدت دارن. ولی وقتی سعی میکنیم قبای بزرگتر از قامتمون تن کنیم، تبدیل به یه شوخی پرهزینه خواهیم شد.
اگر دوست داشتید قسمت بعد رو با همین رویه در مورد مایکروسرویس گپ بزنیم: ⚙️
و اگر دوست داشتید تمایز DDD و domain-centric: 🤪