Fundamentals of Software Architecture: An Engineering Approach

Each architecture characteristic that an architect designs support for potentially complicates the overall design.

There are no wrong answers in architecture, only expensive ones.

To use a physics analogy, software systems model complex systems, which tend toward entropy (or disorder). Energy must be added to a physical system to preserve order. The same is true for software systems: architects must constantly expend energy to ensure good structural soundness, which won’t happen by accident.

Never shoot for the best architecture, but rather the least worst architecture.

To quote Mark (one of your authors): All architectures become iterative because of unknown unknowns, Agile just recognizes this and does it sooner.

One important thing to note is that agility does not equal time to market. Rather, it is agility + testability + deployability. This is a trap many architects fall into when translating domain concerns. Focusing on only one of the ingredients is like forgetting to put the flour in the cake batter. For example, a domain stakeholder might say somethi

Often, the architect is also the technical leader on projects and therefore determines the engineering practices the team uses. Just as architects must carefully consider the problem domain before choosing an architecture, they must also ensure that the architectural style and engineering practices form a symbiotic mesh. For example, a microservice

Too many architecture characteristics leads to generic solutions that are trying to solve every business problem, and those architectures rarely work because the design becomes unwieldy. This suggests that architects should strive to design architecture to be as iterative as possible. If you can make changes to the architecture more easily, you can

Two components are connascent if a change in one would require the other to be modified in order to maintain the overall correctness of the system. Meilir Page-Jones