وقتی قدم به دنیای میکروسرویس ها می گذارید، با سوال های زیادی روبرو می شوید:

  • حوزه و محدوده وظایف هر میکروسرویس چیست؟
  • مرزبندی بیزنسی هر میکروسرویس تا کجاست؟
  • چه کارهایی باید در این میکروسرویس انجام شود و چه کارهایی نباید انجام شود.

برای پاسخ به این سوال ها نیاز است با مفهوم Bounded Context در رویکرد DDD آشنا باشید.

رویکرد Domain Driven Design

در رویکرد Domain Driven Design تمرکز اصلی روی شناخت فضای مسئله بر اساس بیزنس است. همچنین توجه به این که قسمت های مختلف یک سیستم چگونه با هم در تعامل و ارتباط هستند. در این رویکرد، علاوه بر اینکه اصول اولیه شی گرایی باید رعایت شوند، از الگوهای طراحی (Design Patterns) و تکنیک های توسعه مبتنی بر تست (Test Driven Development) هم استفاده می شود.

Ubiquitous Language

Ubiquitous Language زبان مشترک در حوزه دانش دامین است که همه قسمت های یک سیستم با استفاده از واژه های متداول در آن، با یکدیگر ارتباط برقرار می کنند. این واژه ها بایستی همگی مشخص و تک منظوره باشند تا سطح فهم همگان از برنامه نویس تا تحلیل گر بیزنس و آزمونگر، درک یکسانی از معنا و کاربرد آن داشته باشند. حتی بایستی در مستندات پروژه و کدهای قسمت های مختلف از همین واژه ها استفاده شود.

Bounded Context

حال بر اساس همین زبان مشترک و واژه ها و اصطلاحات بیزنسی که همگی از دانش دامین استخراج شده اند، مرز یا محدوده وظایف هر قسمت و نحوه تعامل آن با سایر قسمت ها مشخص می شود.  به صورتی که واژه ها و اصطلاحات هم خانواده که در اصل نمایانگر یک کارکرد خاص دامین هستند، در یک bounded context گنجانده می شوند و مرز مشخصی با bounded context دیگر خواهند داشت و برای ارتباط با یکدیگر ممکن است نیاز به ترجمه و تفسیر مفاهیم در حوزه دانش هریک وجود داشته باشد.

برای مثال یک سیستم رزرو بلیت هواپیما وجود دارد و شرکت تصمیم می گیرد امکان رزرو آنلاین بلیت را هم فراهم کند. در سیستم رزرو آنلاین، مسافر خودش با جستجوی پروازها و بررسی مشخصات آن ها بلیت موردنظرش را درخواست می دهد و پرداخت به صورت آنلاین انجام شده و بلیت صادر می شود. بنابراین موجودیت آژانس مسافرتی که در سیستم قبلی مسئول انجام کلیه این امور بود، دیگر معنایی نخواهد داشت بنابراین خارج از boundry رزرو آنلاین محسوب می شود. از طرفی مسافر، پرواز و بلیت از موجودیت های مشترک دو سیستم هستند و می توان از shared kernel برای کار با موجودیت های مشترک استفاده نمود و یا هر نوع ترجمه و تبدیل دیتا بین دو سیستم را در anti-corruption layer انجام داد.

بنابراین هنگامی که قصد شناخت محدوده وظایف یک میکروسرویس را داریم، با مدد رویکرد DDD می توانیم bounded context میکروسرویس را تعیین نماییم. اما باید بدانیم که آن چه در رویکرد DDD مهم است، این است که در هنگام مطالعه فضای مسئله برای استخراج model باید “به آنچه در حال حاضر هست” توجه کنیم و نه آنچه که می خواهیم باشد و دیگر اینکه این جریان، فرآیندی مستمر است و تغییر همیشه بوده و خواهد بود و باید طوری طراحی کنیم که اعمال تغییرات با کمترین هزینه میسر باشد.