یکی از مهم ترین و چالش برانگیز ترین موضوعات در سیستم های توزیع شده Granularity یا همان سطح جزئیات اجزای سیستم می باشد. Granularity به اندازه یا سطح جزئیاتی که برای تعریف اجزای مختلف سیستم انتخاب می شود اشاره دارد.
خب قبل از شروع بیایید تفاوت بین Modularity و Granularity رو که بیشتر اوقات باهم اشتباه گرفته می شوند را بررسی کنیم:
ماژولار بودن (Modularity): به تقسیم سیستم به بخش های جداگانه و مستقل اشاره دارد که هر بخش وظایف خاصی را انجام می دهد. هدف از ماژولار بودن استفاده مجدد, قابلیت نگهداری و انعطاف پذیری می باشد.
دانه بندی (Granularity): به اندازه یا سطح این بخش های مستقل اشاره دارد. به زبان ساده تر Granularity مشخص می کند یک بخش یا سرویس چقدر باید بزرگ یا کوچک باشد.
اهمیت Granularity
دانه درشت (Coarse-Grained): اگر سرویس هایی که داریم بیش از حد بزرگ باشند پیچدگی های آن افزایش, انعطاف پذیری کاهش و احتمال توسعه مستقل و جزئی سرویس ها کاهش پیدا می کند.
دانه ریز (Fine-Grained): همچنین اگر سرویس ها بیش از حد کوچک باشند تعداد ارتباط بین سرویس ها افزایش پیدا می کند که مدیریت سرویس ها را پیچیده کرده و response time را افزایش می دهد.
معیارهای تعیین سطح Granularity
تعداد دستورات (Number of Statements): تعداد statement ها در هر سرویس به ما نشان می دهد که سرویس چچقدر کار انجام می دهد. اگر یک سرویس تعداد زیادی statement داشته باشد ممکن است بیش از حد بزرگ باشد و نیاز به تفکیک داشته باشد.
تعداد Public Interfaces: تعداد زیاد Public Interface ها نیز به ما نشان می دهد که سرویس مسئولیت های زیادی دارد که نیاز به تفکیک دارد.
تعادل برای انتخاب سطح مناسب Granularity بین دو نیرو متضاد
Granularity Disintegrators: این نیرو زمانی کاربرد دارد که باید یک سرویس به بخش های کوچکتر تقسیم شود. برای مثال اگر یک سرویس دارای چند مسئولیت مختلف می باشد می توان آن را به سرویس های کوچکتر تقسیم کرد تا هر سرویس تنها یک کار خاص را انجام دهد. چه زمانی باید سرویس را به بخش های کوچکتر تقسیم کنیم؟
Granularity Integrators: این نیرو زمانی کاربرد دارد که سرویس های کوچک به دلیل ارتباطات زیاد و پیچیدگی بالا باید در سرویس های بزرگ ترکیب شوند. چه زمانی باید سرویس ها را مجدد ترکیب کنیم(وصل)؟
در پایان, باید به این موضوع توجه داشته باشیم که انتخاب سطح مناسب Granularity یک فرمول ثابت ندارد و بیشتر یک هنر می باشد. برای اینکه بتوانیم تصمیم بهتری در انتخاب این سطح بگیریم باید مزایا و معایب هر سطح را به شکل کامل بررسی کنیم. سرویس ها باید به اندازه ای کوچک باشند که بتوانند به طور مستقل توسعه یابند اما نه آنقدر کوچک که مدیریت و ارتباطات بین ها بیش از حد پیچیده شود.
