Skip to content

Relationship between Tactics and Architectural Styles/Patterns

A tactic is a design decision that influences how a system responds on a quality attribute. Quality attributes are traits such as security or availability (see Quality Attribute).

A pattern is a conceptual solution to a design problem that keeps coming back in a defined context.

A useful comparison: a tactic is an atom, and a pattern is a molecule. A pattern is made of smaller, tactic-level decisions.

Tactics are simpler than patterns. They are also not finished designs. A team still has to realize a tactic through patterns, frameworks and code.

So the two ideas fit together. A tactic names the single decision. A pattern is one way to put such decisions into a concrete structure.

A team wants a system to survive failures. “Keep a spare ready to take over” is a tactic. The team then realizes it through a pattern, a framework and some code. The tactic stays the same. The realization is where the details get decided.

A tactic is simple, but it can have side effects. It may improve its target response while trading off other qualities. A tactic is also not a finished design. The team must still choose how to realize it with patterns, frameworks and code. Those choices add work and further decisions.

A pattern is built from several tactic-level decisions and is then realized in frameworks and code.

Diagram source
flowchart LR
T1[Tactic A] --> P[Pattern]
T2[Tactic B] --> P
T3[Tactic C] --> P
P --> R[Realized through frameworks and code]
  • Each tactic named in the document is described as a design decision aimed at a quality attribute response.
  • The document says how each chosen tactic is realized, for example through a pattern, framework or code.
  • Side effects of a tactic on other quality attributes are noted.