‫۷ سال و ۳ ماه قبل، شنبه ۳ تیر ۱۳۹۶، ساعت ۱۸:۱۹
طبق توضیحات گفته شده در اول مقاله 
«زمانیکه به ازای هر تغییر، نیاز باشد تغییرات کوچکی در تعداد کلاس‌های زیادی انجام شود، این بوی بد کد بوجود آمده است. این الگو از دسته بندی «جلوگیری کنندگان از تغییر» است. نام این دسته بندی به طور واضح گویای مشکلی است که این الگوی بد ایجاد می‌کند.»    
من فکر میکنم اون مسئله‌ای که گفتم شامل همین مباحث هستش و تغییر در PhoneValidator ممکنه تغییرات کوچک زیادی رو شامل بشه.
‫۷ سال و ۳ ماه قبل، شنبه ۳ تیر ۱۳۹۶، ساعت ۱۳:۱۵
دوست عزیز ضمن تشکر از مطلب مفیدتون.بنظرت اون قسمت new PhoneValidator()  کد تکراری به حساب نمیاد و خودش باعث shotgun surgery  نمیشه؟بهتر نیست یک IPhoneValidator داشته باشیم و به کلاس سرویس تزریق کنیم تا در صورتی که تغییری در  PhoneValidator  بوجود اومد کد ما دستخوش تغییر نشه؟
‫۷ سال و ۳ ماه قبل، سه‌شنبه ۳۰ خرداد ۱۳۹۶، ساعت ۰۷:۰۳
سلام.
مایکرو سرویس یکی از مشتقات SOA می‌باشد. اما تفاوت هایی هم تو این دیدگاه نسبت به SOA وجود دارد
  1. اندازه سرویسها در این دو متفاوت می‌باشد در مایکرو سرویسها اندازه یک سرویسها کوچکتر از اندازه سرویسها در SOA می‌باشد
  2. سرویها در مایکرو سرویس می‌توانند کاملا مستقل از هم قابل استقرار باشندو مکانیزم استقار بصورت خودکار می‌باشد درحالی که در SOA  این امکان وجود ندارد
  3. در SOA  برای بررسی قوانین کسب و کار  و ادغام سیستم‌های یکپارچه  تمرکزبر روی ESB  می باشد ، در حالی که این امر در مایکرو سرویس‌ها یک anti pattern  به شمار می‌آید و دیدگاه  آنها عدم انتقال قوانین کسب کار به مکانیزم ارتباطی می‌باشد (smart endpoints and dumb pipe)
در مورد معایب این روش در آینده صحبت خواهیم کرد اما میتوان گفت که پیاده سازی این معماری هزینه زیادی دارد هم از لحاظ زمانی و هم از لحاظ پیچیدگی در پیاده سازی.