4 ms·

The article is describing, in a less clear way than they could, a clear separation of concerns in code. This is a good practice, especially for complex code. T

The article is describing, in a less clear way than they could, a clear separation of concerns in code. This is a good practice, especially for complex code. There is a tradeoff though: adding too many layers of indirection makes changes just as complicated as if you wrote a big ball of spaghetti (oh, just propagate this field across all 10 layers!), and that your team needs to be diligent about making changes to the correct layers. With a small, high-quality team this absolutely pays dividends in terms of ease of migration and changes, but you need to ensure there is good knowledge of the architecture spread across multiple people. The ideal place for this is in code with unclear, or rapidly changing business requirements. Note that this doesn't prevent you from getting bogged down by excessive complexity -- it literally just limits the blast radius of this complexity and makes the inevitable future refactorings smaller in scope.

chipdart 2y ago
> 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.
mcphage 2y ago
> adding too many layers of indirection makes changes just as complicated as if you wrote a big ball of spaghetti (oh, just propagate this field across all 10 layers!), and that your team needs to be diligent about making changes to the correct layers. "Layers of abstraction can solve any problem in software design, except for having too many layers of abstraction" :-)

chipdart 2y ago

> 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.

mcphage 2y ago

> adding too many layers of indirection makes changes just as complicated as if you wrote a big ball of spaghetti (oh, just propagate this field across all 10 layers!), and that your team needs to be diligent about making changes to the correct layers. "Layers of abstraction can solve any problem in software design, except for having too many layers of abstraction" :-)