آموزش Scope کردن میکروسرویس ها و Event Storming

آموزش ویدئویی Scope کردن و سازماندهی کردن مایکروسرویس ها در دات نت با استفاده از Event Storming یکی دیگر از آموزش های گروه آموزشی پرووید می باشد که در این قسمت آن را به شما معرفی می کنیم. این بسته ی آموزشی نیز یکی از دوره های آموزشی دیگر که در حوزه ی فارسی سازی آموزش های انگلیسی تنظیم شده است می باشد. عنوان این بسته آموزشی مفاهیم Scoping و سازماندهی Microservices با استفاده از Event Storming است که با نام اصلی Scoping and Organizing .NET Microservices Using Event Storming از شرکت Pluralsight منتشر شده است.

فرآیند Event Storming چگونه کار می کند؟

یکی از اولین چیزهایی که باید بدانید، انواع مختلفی از جزئیات است که در مورد دامنه ثبت می شود. این انواع مختلف از جزئیات، معمولاً در قالب برچسب هایی که رنگ های متفاوتی دارند نشان داده می شوند. بیایید هر یک از اینها را با جزئیات مرور کنیم:

Events (orange): رویدادها که به رنگ نارنجی هستند. این جزئیات مهمترین و پرکاربردترین مؤلفه در event storm هستند و نشان دهنده رویدادهای دامنه و هر چیزی هستند که به domain expert مربوط می شود. آنها به زمان گذشته نوشته می شوند و جزئیات اساسی را ارائه می دهند که بصورت طبقه بندی شده وارد مرحله بعد شوند.

Commands (blue): دستورات که به رنگ آبی هستند. این جزئیات درخواست هایی برای انجام کاری خاص هستند. آنها می توانند از یک کاربر یا سیستم یا توسط event دیگری سرچشمه بگیرند.

System (pink): سیستم که به رنگ صورتی می باشد. این جزئیات نمایانگر سیستم های مرتبط با domain هستند. آنها ممکن است دستوراتی صادر کنند یا دستوراتی را همراه با ایجاد رویدادها دریافت کنند.

User (yellow): کاربران که به رنگ زرد هستند. اینها مشخص کننده کاربران انسانی یا کاربرانی هست که در فرآیند مشارکت دارند. آنها ممکن است یک فرد یا یک بخش یا یک تیم باشند. این برچسب های زرد نشان می‌دهند که روند کاری یک فرآیند تجاری چگونه می‌تواند بر اساس تعداد department هایی که در آن وجود دارند و تعداد تعاملات پیچیده باشد.

Aggregate (tan): برچسب رنگ برنزی که اولین سطح از دسته بندی است و می تواند به عنوان یک "چیز" در نظر گرفته شود که گروهی از رویدادها روی آن کار می کنند. معمولاً آنها یک اسم هستند و زمانی که مجموعه ای از رویدادها به یکدیگر وابسته هستند، قابل شناسایی هستند.

Read Model (green): برچسب رنگ سبز که نشان دهنده، داده هایی است که ممکن است برای یک کاربر یا سیستم برای تصمیم گیری حیاتی باشد. اغلب از این مورد استفاده نمی شود، اما زمانی که نیاز به تأکید بر داده‌هایی که کاربر می‌بیند باشد، این برچسب می‌تواند مفید باشد.

میکروسرویس‌ها در معماری .NET چگونه سازمان‌دهی می‌شوند؟

معماری میکروسرویس رویکردی برای طراحی نرم‌افزار است که در آن سیستم به سرویس‌های کوچک‌تر با مسئولیت‌های مشخص تقسیم می‌شود. هر سرویس بخشی از قابلیت‌های کسب‌وکار را پوشش می‌دهد و از طریق قراردادهای ارتباطی تعریف‌شده با بخش‌های دیگر تعامل می‌کند. در پروژه‌های .NET، تعیین مرز مناسب میان سرویس‌ها اهمیت زیادی دارد؛ زیرا تقسیم‌بندی نامناسب می‌تواند وابستگی‌های غیرضروری ایجاد کند و مدیریت سیستم را دشوارتر سازد. سازمان‌دهی درست میکروسرویس‌ها نیازمند شناخت دامنه کسب‌وکار و روابط میان قابلیت‌های مختلف آن است.

پیش از پیاده‌سازی میکروسرویس‌ها، باید مشخص شود هر سرویس چه مسئولیت‌هایی دارد و کدام بخش‌های سیستم به یکدیگر وابسته هستند. اگر مرز سرویس‌ها بدون بررسی کافی تعیین شود، ممکن است تغییر یک قابلیت به اصلاح چندین سرویس نیاز پیدا کند یا منطق یکسان در بخش‌های مختلف تکرار شود. تحلیل دامنه و بررسی جریان‌های کاری به تیم کمک می‌کند تقسیم‌بندی آگاهانه‌تری انجام دهد. این کار می‌تواند مبنای مناسبی برای طراحی ساختار نرم‌افزار و تعیین مسئولیت‌های اجزای مختلف در پروژه‌های مبتنی بر .NET فراهم کند.

تعیین مرز میکروسرویس‌ها با Domain-Driven Design

تعیین مرز میکروسرویس‌ها یکی از تصمیم‌های مهم در طراحی سیستم‌های توزیع‌شده است. رویکرد Domain-Driven Design یا DDD بر شناخت دقیق دامنه کسب‌وکار و مدل‌سازی مفاهیم اصلی آن تأکید دارد. با بررسی قوانین، اصطلاحات و مسئولیت‌های مرتبط با هر بخش از کسب‌وکار، می‌توان به درک بهتری از محدوده‌های منطقی سیستم رسید. این شناخت به تیم توسعه کمک می‌کند سرویس‌ها را بر اساس مسئولیت‌های معنادار طراحی کند، نه صرفاً بر اساس ساختار فنی یا تقسیم‌بندی فایل‌ها و کلاس‌ها.

در این فرایند، باید مشخص شود کدام قابلیت‌ها به یک حوزه کسب‌وکار تعلق دارند و کدام بخش‌ها بهتر است مسئولیت مستقلی داشته باشند. مرزهای مناسب می‌توانند وابستگی میان سرویس‌ها را کاهش دهند و امکان تغییر مستقل‌تر بخش‌های مختلف را فراهم کنند. البته تعیین این مرزها همیشه ساده نیست و به پیچیدگی دامنه و روابط میان قابلیت‌ها بستگی دارد. استفاده از روش‌های تحلیل و گفت‌وگو درباره فرایندهای کسب‌وکار به تیم کمک می‌کند تصمیم‌های طراحی را بر اساس شناخت مشترک و شواهد روشن‌تری اتخاذ کند.

Shared Components در معماری میکروسرویس‌ها چه کاربردی دارند؟

در معماری میکروسرویس‌ها، گاهی چند سرویس به قابلیت‌ها یا اجزای فنی مشترکی نیاز دارند. این اجزا ممکن است شامل قراردادهای مشترک، مدل‌های محدود و بخش‌هایی از کد باشند که استفاده مجدد از آن‌ها در چند پروژه منطقی است. بااین‌حال، مشترک کردن بیش از حد اجزا می‌تواند وابستگی میان سرویس‌ها را افزایش دهد و استقلال آن‌ها را کاهش دهد. بنابراین، هنگام طراحی Shared Components باید مشخص شود کدام بخش‌ها واقعاً نیازمند استفاده مشترک هستند و کدام قابلیت‌ها بهتر است در محدوده یک سرویس باقی بمانند.

تصمیم درباره ایجاد یک کامپوننت مشترک باید با توجه به مسئولیت سرویس‌ها و میزان وابستگی آن‌ها اتخاذ شود. اگر چند سرویس به یک قرارداد فنی مشخص نیاز داشته باشند، اشتراک‌گذاری آن می‌تواند از تکرار غیرضروری جلوگیری کند. اما اگر منطق کسب‌وکار دو سرویس تنها شباهت ظاهری داشته باشد، انتقال آن به یک جزء مشترک ممکن است تغییرات آینده را پیچیده‌تر کند. در پروژه‌های .NET، توجه به این تفاوت به توسعه‌دهندگان کمک می‌کند ساختار پروژه را بهتر سازمان‌دهی کنند و میان استفاده مجدد از کد و استقلال سرویس‌ها تعادل برقرار سازند.

نقش Event Storming در طراحی معماری میکروسرویس‌ها

Event Storming روشی برای بررسی و مدل‌سازی فرایندهای کسب‌وکار است که در آن رویدادهای مهم دامنه شناسایی می‌شوند و ارتباط میان آن‌ها مورد بحث قرار می‌گیرد. این روش می‌تواند به اعضای تیم کمک کند تصویر مشترک‌تری از نحوه عملکرد سیستم به دست آورند و جریان فعالیت‌ها را بهتر درک کنند. با بررسی رویدادها و روابط میان آن‌ها، بخش‌هایی از فرایند کسب‌وکار که مسئولیت‌های متفاوتی دارند آشکارتر می‌شوند و زمینه مناسبی برای بررسی مرزهای احتمالی میکروسرویس‌ها فراهم می‌شود.

در پروژه‌های مبتنی بر .NET، نتایج Event Storming می‌توانند در تصمیم‌گیری درباره محدوده سرویس‌ها و نحوه سازمان‌دهی اجزای مشترک مورد استفاده قرار گیرند. این روش به‌تنهایی معماری نهایی را تعیین نمی‌کند، اما پرسش‌های مهمی درباره مسئولیت‌ها، تعاملات و وابستگی‌های دامنه مطرح می‌سازد. گفت‌وگو میان افراد آشنا با کسب‌وکار و توسعه‌دهندگان فنی کمک می‌کند تصمیم‌های طراحی بر پایه درک دقیق‌تری از نیازهای سیستم گرفته شوند. ترکیب تحلیل دامنه با بررسی عملی مرزها می‌تواند به شکل‌گیری معماری منسجم‌تر و قابل نگهداری‌تر کمک کند.