> The article is describing, in a less clear way than they could, a clear separation of concerns in code. My take is a bit harsher. The article tries to reinve

> The article is describing, in a less clear way than they could, a clear separation of concerns in code. My take is a bit harsher. The article tries to reinvent the wheel -- poorly -- and fails to do the faintest and most superficial researches on a topic which is already covered in basic courses on software engineering. Layered architecture is a ubiquitous name in any work on software architecture, such as popular offshoots such as Uncle Bob's Clean Architecture. They describe the benefits of organizing software projects around layers, but go a step beyond and effectively solve the problem by also classify what kind of responsibilities should be assigned to each layer and how the dependency relationships between layers should be managed and enforced. I'm talking about basic principles such as internal/lower-level layers should contain code that changes the least frequently. There are also some software architectures which abandon the whole concept of layer and instead specify organizing the project in independemt submodules implementing/sharing common interfaces, and have root project handle only integration. This is often dubbed horizontal architecture as in all modules are laid out horizontally, as in they specify no dependency relationships with modules represented above or below, instead of vertically, as in modules are expected to comply with a fixed relationship archetype.