Fundamentals of Software Architecture: An Engineering Approach

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

Programmers know the benefits of everything and the trade-offs of nothing. Architects need to understand both.

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

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.

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

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

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

In this definition, software architecture consists of the structure of the system (denoted as the heavy black lines supporting the architecture), combined with architecture characteristics (“-ilities”) the system must support, architecture decisions, and finally design principles.