تو کتاب Designing Event Driven Systems به این موضوع اشاره شده که همه ما تو مهندسی نرم افزار یاد گرفتیم که کدها و سرویس هامون رو کپسوله کنیم. یعنی مسئولیت های هر کدوم از بخش های سیستم رو به طور مستقل تعریف کنیم. مثلاً یه سرویس لاگین تک مرحله ای (SSO) کاملاً مسئولیت مشخص و محدودی داره و از بقیه بخش های سیستم جداست، به شکلی که در صورت نیاز به تغییرات زیاد هم احتمالش کم هست که به این سرویس دست بزنیم.
در ادامه میگه تو دنیای واقعی این کار به این شکل تمیز و مرتب نیستش. وقتی Business Service های مختلف داریم به سختی میشه این جداسازی تمیز رو حفظ کرد. نیازهای جدید ممکنه از Service Boundaries عبور کنند و باعث بشن که چندتا سرویس همزمان تغییر کنند. مثلا اگر قراره یه قابلیت جدید تو یک تیم پیاده سازی بشه و نیاز به تغییر کد تو یک تیم دیگه هستش, دیگه نمی تونیم با همون سرعت قبل تغییرات رو انجام بدیم و نیاز به هماهنگی بین تیم ها و نسخه ها داریم که این هماهنگی ها معمولا باعث کاهش چابکی و انعطاف پذیری سیستم می شوند.
همچنین میگه که این مشکل فقط مربوط به سرویس ها نیستش, حتی Shared Library ها هم این چالش رو دارند. اشاره میکنه زمانی که OOP تازه مد شده بود همه دوست داشتن یک Library بسازن که توش مدل Order ها, Client ها, Payment ها و غیره رو داشته باشند. ولی به مرور متوجه شدن که این کار مشکل و دردسر زیادی داره, چون قراره اون بخش های مهم سیستم رو به کلی برنامه دیگه وصل کنه برای همین هر تغییر کوچکی در اون باعث مشکل تو کل برنامه ها میشه.
در ادامه میگه که معمولا میکروسرویس ها یک Domain Model مشترک ندارند. چون اگر Domain Model مشترکی وجود داشته باشه, تغییرات تو یک بخش از سیستم می تونه باعث تغییرات زیادی تو بقیه بخش ها بشه. البته یکسری Library مثل Logging رو میشه به اشتراک گذاشت چون خیلی بعید هستش که تغییرات Business روشون تاثیر بزاره.
در پایان, به نظر من تو دنیای واقعی هیچ چیزی به سادگی کتاب ها پیش نمیره. کپسوله سازی و جداسازی سرویس ها ایده های خوبی هستن, ولی باید قبول کنیم که نیازهای جدید به راحتی باعث شکسته شدن این مرزها میشن. گاهی اوقات شاید بهتر باشه از اصولی که بهشون باور داشتیم/داریم فاصله بگیریم و به نیازهای Business فکر کنیم تا اصول مهندسی. به عبارت دیگه به جای چسبیدن به راه حل های ثابت سعی کنیم انعطاف پذیری داشته باشیم و بتونیم با شرایط تغییر کنیم. به جای اینکه اصرار داشته باشیم همه چیز رو مستقل و کپسوله نگه داریم بهتره که یاد بگیریم چطور با وابستگی ها کنار بیاییم و مدیریتشون کنیم. بین استقلال سرویس ها و نیاز به همکاری تعادل برقرار کنیم. هنر طراحی نرم افزار در این هستش که بدونیم کجا باید انعطاف پذیر باشیم و کجا رو اصول پافشاری کنیم.
