It depends! With all the choices available (and new ones arriving almost daily), we would like to tell you which one to use—but we cannot. Nothing is more contextual to a number of factors within an organization and what software it builds. Choosing an architecture style represents the culmination of analysis and thought about tradeoffs for architecture characteristics, domain considerations, strategic goals, and a host of other things.
However contextual the decision is, some general advice exists around choosing an appropriate architecture style.
Preferred architecture styles shift over time, driven by a number of factors.
New architecture styles generally arise from observations and pain points from past experiences. Architects have experience with systems in the past that influence their thoughts about future systems (sometimes too much influence from past experiences—see Example 18-1). Architects must rely on past experience—it is that experience that allowed that person to become an architect in the first place. Often, new architecture designs reflect specific deficiencies from past architecture styles. For example, architects seriously rethought the implications of code reuse after building architectures that feature it, then realized the negative tradeoffs.
Constant change is a reliable feature of the software development ecosystem—everything ...