قوانین برای اطاعت احمقان و راهنمایی خردمندان است.
خوانده شده در کتاب #Building_Microservices

Playing by the rules is important when it comes to response codes, too. If your circuit breakers rely on HTTP codes, and one service decides to send back 2XX codes for errors, or confuses 4XX codes with 5XX codes, then these safety measures can fall apart. Similar concerns would apply even if you’re not using HTTP; knowing the difference between a request that was OK and processed correctly, a request that was bad and thus prevented the service from doing anything with it, and a request that might be OK but we can’t tell because the server was down is key to ensuring we can fail fast and track down issues. If our services play fast and loose with these rules, we end up with a more vulnerable system.

نکته ش همون شوخی معروفیه که بین فرانت اند کارها و بکند کارها رایجه:
"عملیات با موفقیت با شکست مواجه شد!"
اصلا چرا ما لجاجت داریم که همیشه 200 برگردونیم ؟ پس کی میخوایم این RESTful بدبخت رو جدی بگیریم ؟
در مورد استفاده نکردن از PUT و PATCH هم که چیزی نگم بهتره :))
✅توضیح جدی:
مسئله ی مهمی که کتاب در این بخش داره توضیح میده مسئله ی Architectural Safety هست، خوب ما از مکانیزم های مختلفی برای مانیتورینگ استفاده میکنیم، اگه قرار باشه این Status ها قابل اعتماد نباشن، کل اون ماجرا به فنا میره که هیچ .... ارتباط بین سرویس هامون هم نمیشه دیگه بهش اعتماد داشت.
پس اگر از این Status ها درست و به جا استفاده کنیم اینطوری احتمال شکنندگی سیستم رو کاهش دادیم :)
در کل ماجرای Status ها در این بخش مثال هست و مثال خوبی هم هست، ولی مسئله فقط به اینجا ختم نمیشه، پارامترهای دیگه ای هم هست که سر فرصت شاید نشستیم با هم در مورد جلوگیری از شکنندگی سیستم ها راهکارهاش گپ زدیم.

فصل دوم کتاب #Building_Microservices

Sometimes, the group may make decisions with which the architect disagrees. At this point, what is the architect to do? Having been in this position before, I can tell you this is one of the most challenging situations to face. Often, I take the approach that I should go with the group decision. I take the view that I’ve done my best to convince people, but ultimately I wasn’t convincing enough. The group is often much wiser than the individual, and I’ve been proven wrong more than once! And imagine how disempowering it can be for a group to have been given space to come up with a decision, and then ultimately be ignored. But sometimes I have overruled the group. But why, and when? How do you pick the lines?
Think about teaching children to ride a bike. You can’t ride it for them. You watch them wobble, but if you stepped in every time it looked like they might fall off, then they’d never learn, and in any case they fall off far less than you think they will! But if you see them about to veer into traffic, or into a nearby duck pond, then you have to step in.
Likewise, as an architect, you need to have a firm grasp of when, figuratively, your team is steering into a duck pond. You also need to be aware that even if you know you are right and overrule the team, this can undermine your position and also make the team feel that they don’t have a say. Sometimes the right thing is to go along with a decision you don’t agree with. Knowing when to do this and when not to is tough, but is sometimes vital.

#Building_Microservices

be aware of the perils of shared code. In our desire to create reusable code, we can introduce sources of coupling between services. At least one organization I spoke to is so worried about this that it actually copies its service template code manually into each service. This means that an upgrade to the core service template takes longer to be applied across its system, but this is less concerning to it than the danger of coupling. Other teams I have spoken to have simply treated the service template as a shared binary dependency, although they have to be very diligent in not letting the tendency for DRY (don’t repeat yourself) result in an overly coupled system!

#Building_Microservices