مرزهای مدل دامنه را برای هر میکروسرویس شناسایی کنید

هدف از شناسایی مرزها و اندازه مدل برای هر میکروسرویس رسیدن به جداسازی دانه ای ممکن نیست، اگرچه در صورت امکان باید به سمت میکروسرویس های کوچک گرایش پیدا کنید. در عوض، هدف شما باید رسیدن به معنی‌دارترین جدایی باشد که توسط دانش دامنه شما هدایت می‌شود. تاکید بر اندازه نیست، بلکه بر قابلیت های تجاری است. علاوه بر این، اگر انسجام واضحی برای یک منطقه خاص از برنامه بر اساس تعداد زیادی وابستگی وجود داشته باشد، این نشان دهنده نیاز به یک میکروسرویس واحد نیز هست. انسجام راهی برای شناسایی نحوه جدا کردن یا گروه بندی میکروسرویس ها است. در نهایت، در حالی که دانش بیشتری در مورد دامنه به دست می آورید، باید اندازه میکروسرویس خود را به طور مکرر تطبیق دهید. یافتن اندازه مناسب یک فرآیند یکباره نیست.سام نیومن، مروج شناخته شده میکروسرویس ها و نویسنده کتاب Building Microservices، تاکید می کند که باید میکروسرویس های خود را بر اساس الگوی Bounded Context (BC) (بخشی از طراحی دامنه محور) طراحی کنید، همانطور که قبلاً معرفی شد. گاهی اوقات، یک BC می تواند از چندین سرویس فیزیکی تشکیل شده باشد، اما نه برعکس.یک مدل دامنه با موجودیت های دامنه خاص در یک BC بتن یا میکروسرویس اعمال می شود. BC کاربرد یک مدل دامنه را مشخص می‌کند و به اعضای تیم توسعه‌دهنده درک واضح و مشترکی از آنچه باید منسجم باشد و آنچه که می‌توان به طور مستقل توسعه داد می‌دهد. اینها همان اهداف برای میکروسرویس ها هستند.یکی دیگر از ابزارهایی که به انتخاب طراحی شما اطلاع می دهد قانون کانوی است که بیان می کند یک برنامه منعکس کننده مرزهای اجتماعی سازمانی است که آن را تولید کرده است. اما گاهی اوقات برعکس است - سازمان شرکت توسط نرم افزار تشکیل شده است. ممکن است لازم باشد قانون کانوی را معکوس کنید و مرزها را طوری بسازید که می خواهید شرکت سازماندهی شود و به سمت مشاوره فرآیندهای تجاری متمایل شود.برای شناسایی زمینه های محدود، می توانید از یک الگوی DDD به نام الگوی نگاشت زمینه استفاده کنید. با Context Mapping، زمینه های مختلف برنامه و مرزهای آنها را شناسایی می کنید. برای مثال، برای هر زیرسیستم کوچک، زمینه و مرز متفاوتی وجود دارد. نقشه زمینه راهی برای تعریف و مشخص کردن مرزهای بین دامنه ها است. یک BC مستقل است و شامل جزئیات یک دامنه واحد - جزئیاتی مانند موجودیت های دامنه - است و قراردادهای یکپارچه سازی را با سایر BC ها تعریف می کند. این شبیه به تعریف میکروسرویس است: مستقل است، قابلیت دامنه خاصی را پیاده سازی می کند و باید رابط هایی را ارائه دهد. به همین دلیل است که Context Mapping و الگوی Bounded Context رویکردهای خوبی برای شناسایی مرزهای مدل دامنه میکروسرویس‌های شما هستند.هنگام طراحی یک برنامه کاربردی بزرگ، خواهید دید که چگونه مدل دامنه آن می تواند تکه تکه شود - به عنوان مثال، یک متخصص دامنه از دامنه کاتالوگ، نام نهادها را در حوزه کاتالوگ و موجودی متفاوت از یک متخصص دامنه حمل و نقل می کند. یا زمانی که با یک متخصص CRM که می‌خواهد تمام جزئیات مشتری را ذخیره کند، ممکن است موجودیت دامنه کاربر از نظر اندازه و تعداد ویژگی‌ها متفاوت باشد تا کارشناس دامنه سفارش‌دهنده که فقط به داده‌های جزئی درباره مشتری نیاز دارد. ابهام‌زدایی از همه اصطلاحات دامنه در همه دامنه‌های مرتبط با یک برنامه کاربردی بسیار سخت است. اما مهمترین چیز این است که شما نباید سعی کنید شرایط را یکسان کنید. در عوض، تفاوت ها و غنای ارائه شده توسط هر دامنه را بپذیرید. اگر سعی کنید یک پایگاه داده یکپارچه برای کل برنامه داشته باشید، تلاش برای ایجاد یک واژگان یکپارچه دشوار خواهد بود و به نظر هیچ یک از متخصصان چند دامنه درست نخواهد بود. بنابراین، BC ها (که به عنوان میکروسرویس پیاده سازی می شوند) به شما کمک می کنند تا مشخص کنید کجا می توانید از اصطلاحات دامنه خاصی استفاده کنید و کجا باید سیستم را تقسیم کنید و BC های اضافی با دامنه های مختلف ایجاد کنید.اگر روابط قوی بین مدل‌های دامنه کمی داشته باشید، می‌دانید که مرزها و اندازه‌های مناسب هر مدل BC و دامنه را دریافت کرده‌اید، و معمولاً نیازی به ادغام اطلاعات از مدل‌های چند دامنه در هنگام انجام عملیات برنامه معمولی ندارید.شاید بهترین پاسخ به این سوال که یک مدل دامنه برای هر میکروسرویس چقدر باید بزرگ باشد، این است: این مدل باید یک BC مستقل داشته باشد، تا حد امکان جدا شده، که شما را قادر می سازد بدون نیاز به تغییر مداوم به زمینه های دیگر کار کنید (میکروسرویس های دیگر مدل ها). با این حال، ممکن است موجودیت هایی نیز داشته باشید که شکل متفاوتی دارند اما هویت یکسانی را در مدل های چند دامنه از چندین میکروسرویس به اشتراک می گذارند. به عنوان مثال، موجودیت کاربر در میکروسرویس مدیریت کنفرانس ها شناسایی می شود. همان کاربر، با همان هویت، شخصی است که در میکروسرویس سفارش، خریدار نام دارد، یا در میکروسرویس پرداخت به نام Payer، و حتی در میکروسرویس خدمات مشتری، مشتری نام دارد. این به این دلیل است که بسته به زبانی که هر متخصص دامنه استفاده می‌کند، کاربر ممکن است دیدگاه متفاوتی داشته باشد، حتی با ویژگی‌های متفاوت. موجودیت کاربر در مدل میکروسرویس به نام مدیریت کنفرانس ها ممکن است بیشتر ویژگی های داده های شخصی خود را داشته باشد. با این حال، همان کاربر به شکل پرداخت کننده در پرداخت میکروسرویس یا به شکل مشتری در خدمات مشتری میکروسرویس ممکن است به لیستی از ویژگی ها نیاز نداشته باشد.هنگام تجزیه یک مدل داده سنتی بین زمینه‌های محدود، می‌توانید موجودیت‌های مختلفی داشته باشید که هویت یکسانی دارند (خریدار نیز کاربر است) با ویژگی‌های متفاوت در هر بافت محدود. می‌توانید ببینید که چگونه کاربر در مدل ریزسرویس مدیریت کنفرانس‌ها به‌عنوان موجودیت کاربر حضور دارد و همچنین در قالب موجودیت خریدار در میکروسرویس قیمت‌گذاری، با ویژگی‌ها یا جزئیات جایگزین در مورد کاربر زمانی که در واقع خریدار است، حضور دارد. هر میکروسرویس یا BC ممکن است به همه داده‌های مربوط به یک موجودیت کاربر نیاز نداشته باشد، فقط بخشی از آن، بسته به مشکلی که باید حل شود یا زمینه. به عنوان مثال، در مدل میکروسرویس Pricing، شما به آدرس یا نام کاربر نیازی ندارید، فقط به شناسه (به عنوان هویت) و وضعیت نیاز دارید که در هنگام قیمت گذاری صندلی ها به ازای هر خریدار بر تخفیف ها تأثیر می گذارد.موجودیت Seat در هر مدل دامنه، نام یکسانی دارد اما ویژگی‌های متفاوتی دارد. با این حال، Seat هویت را بر اساس همان شناسه به اشتراک می گذارد، همانطور که برای کاربر و خریدار اتفاق می افتد.اساساً، یک مفهوم مشترک از یک کاربر وجود دارد که در چندین سرویس (دامنه) وجود دارد، که همگی هویت آن کاربر را به اشتراک می گذارند. اما در هر مدل دامنه ممکن است جزئیات اضافی یا متفاوتی در مورد موجودیت کاربر وجود داشته باشد. بنابراین، باید راهی برای نگاشت یک موجودیت کاربر از یک دامنه (microservice) به دامنه دیگر وجود داشته باشد.به اشتراک گذاشتن یک موجودیت کاربری مشابه با تعداد مشخصه های یکسان در دامنه ها مزایای متعددی دارد. یکی از مزایای آن کاهش تکرار است، به طوری که مدل های میکروسرویس هیچ داده ای را که نیاز ندارند ندارند. مزیت دیگر داشتن یک میکروسرویس اولیه است که دارای نوع خاصی از داده ها در هر نهاد است، به طوری که به روز رسانی ها و جستجوهای مربوط به آن نوع داده تنها توسط آن میکروسرویس انجام می شود.