This article has some contradictions: >> Third, we had practically no references to the common architecture patterns and other jargon referenced in common soft

This article has some contradictions: >> Third, we had practically no references to the common architecture patterns and other jargon referenced in common software architecture literature, such as Martin Fowler's architecture guide. No mentions of microservices, serverless architecture Then a few paragraphs later: >> Is your architecture split into different microservices? Mention why you decided against going with a monolith, that might have some other benefits Another contradiction (which mostly contradicts the general premise of the article): >> We created plenty of diagrams, but none of them followed any strict rules. Just plain old boxes and arrows, similar [this one describing information flow] or [this one outlining class structure and relationships between components] In the last link ([this one outlining class structure and relationships between components]), the article says: >> If you have previously worked with the [VIPER] architecture, then the class breakdown of a RIB will look familiar to you. RIBs are usually composed of the following elements, with every element implemented in its own class: ... and then it shows some kind of class diagram which looks vaguely like UML in which the classes have highly architected names like 'Interactor', 'Presenter', 'View', 'Builder'... Nothing to do with the underlying business domain. Doesn't look like simple design to me. The recommended approach looks more like complex VIPER architecture.