3 ms·

> Shared data structures? Common library? Services have an API. If you are sharing data structures and a common "core" library across services, yes, you are off

> Shared data structures? Common library? Services have an API. If you are sharing data structures and a common "core" library across services, yes, you are officially doing it wrong. I agree w/ your other take re: the database but don't understand this one. Sharing data structures between client and server, particularly request/response structures, is hugely useful, certainly not an antipattern. And similarly the idea that if you share a common lib across service boundaries then that's "wrong" falls apart at even the most cursory glance. Service A and B both depend on Service C. So there's a shared client library/SDK that Service A and B use. As just a trivial example.

preseinger 3y ago
if you share data structures in this way you're introducing source-level coupling between services but one of the major reasons to break up logic into separate services is to eliminate source-level coupling a consumer should not need to import service X's SDK in order to use service X, if that is the case then it introduces all kinds of bad situations like "well if i change my service X's behavior in some backwards-incompatible way, it's fine, as long as i update the SDK appropriately" -- wrong etc. etc.