> TL;DR Good engineering requires high awareness even in cases that may appear basic & straightforward. So-called good practice, if overdone or applied incorrectly can be very detrimental & in the same time may appear completely innocent & harmless, making us look for problems' root cause elsewhere. Using...
.Disclaimer: by "architecture in the wild" I mean situations (I've personally encountered) where sheer reality surpasses known (& somehow theoretical) standards / patterns :) in a way that does not impose any obvious solution. It doesn't mean (usually) that everything is so utterly broken, in majority...
In 2016 pretty much every commercial software system built with modern tech is a distributed system. Yes, we all build distributed systems these days. Obviously, the term "distributed" is very spacious - I'm not saying we're all creating stuff like eventually consisted, sharded data...
It usually looks like this: there's already a decision about new product / project, people are extremely happy & eager to start straight away, silently expecting to "do it all perfectly" this time, avoiding all the mistakes from the past. But before they get into actual work,...
This is part III of coupling consideration topic. If you want to check my past coupling-related posts, you can find them here: * Part I [http://gebski.tumblr.com/post/76150235763/the-silent-assassin-that-knows-no-mercy-how] - the theory of coupling * Part II [http://gebski.tumblr.com/post/77632428220/the-silent-assassin-that-knows-no-mercy-how] - practical examples of coupling...
