In this scenario, the US parent company does not have physical access to the data, so it needs to request it from the EU subsidiary. The subsidiary then refuses the transfer to comply with German law.
The goal is to design the services and corporate structure in such a way that, if the parent company was forced by US law to try to get ESC data, the operator would be forced by EU law to not comply. In extremis, the partition would be shut down, rather than release the data.
I think we're moving past this fear, thankfully. When you look at newer Java features (records, destructuring, value types) you see that even in the most stereotypical OOP language we are developing a language to describe both behavior (what we always had, with SOLID and domain classes and so on), but also a lightweight language to operate on pure data.
I agree with the article for the most part (except the last snippet where the author reverted to bare, mutable fields), but the point was very badly argued.
I think we really need to consider that sometimes you want a place to hold together data, and some other times you are encoding some behavioral trait, and prior to records Java did not have a way of distinguishing between them.
My rule of thumb is to avoid exposing data in behavioral classes, and prefer immutable patterns for data holders. But sometimes it's not possible to not have setters (e.g. for builders and for JPA entities).
I’m a young Portuguese that left the country for better opportunities, part of the demographic this “author” claims to care for, and it’s hard to not feel disgust at the cynicism and extreme liberal bias.
Apparently everything is the socialists’ fault and the center right parties just didn’t kowtow to fascists hard enough.
It's even worse than that: the so-called "center right" party was explicitly formed to emulate Olof Palme and the nordic social democracies (as the name implies). Only after the troika intervention did PPC pushed it to the neoliberal right.
