Architecture driven by engineering AKA security, authorization, performance, processes and timing, data flow, user/system interaction, hardware devices etc. can

Architecture driven by engineering AKA security, authorization, performance, processes and timing, data flow, user/system interaction, hardware devices etc. can inform/define what the subsystems are. The architecture in the article here seems to be driven by a certain type of OO data/interface-modelling: In school/courses/tutorials/books we are initially taught a type of object oriented data-modelling, which is at the level of: objects in the world are objects in our programs. A person is a Person class, a shopping cart is a ShoppingCart class. You can put stuff into the ShoppingCart, it belongs to a Person and so on. I call this "Kindergarten-OO": It puts labels on things in the world and then models software interactions 1:1 based on that, as if software is a simulation of the world. This conflates all kinds of things and the actual engineering and user-interaction requirements get smeared all over your codebase. Now this kind of Microservice design looks kind of like that but lifted up to a network of computers. You end up with suggestions like: "Design applications around eventual consistency" (article). Why? Because you didn't design your architecture around timing processes, data-structures/-flow and interactions, but around this made up simulation with ~N^2 communication channels. A process that takes a longish time and maybe doesn't need to be real-time consistent: Analytics. Let that be eventually consistent, close the feedback loop each Friday and enrich your data which then informs the rendering (ordering, emphasis of products and so on) on your front-end. An architecture around interactions, flow, data-processing, security/auth and so on looks much more like a decision tree, state-machine or something like that, rather than like a zettelkasten graph.