Context
Software engineering has software design patterns (e.g. GoF), which describe solutions to common coding problems - usually at the code-level; similarly there are architectural patterns (e.g. Fowler) that deal with system architecture in general (whilst these deal with considerations outside of pure code, they often seem to focus more on software engineering concerns rather than infrastructure concerns).
I've also noticed platform providers like Microsoft putting out "cloud design patterns".
Infrastructure as Code (IoC) is a further complication where software/coding-level considerations start to become relevant.
Specific Question(s)
In the realm of Infrastructure, are infrastructure-orientated patterns even a thing? If so, is there any relatively definitive collection of them that is widely understood by the infrastructure community? Or do you just 'borrow' system architecture patterns?
As an aside, assuming the answer to the above is broadly "yes", are cloud infrastructure patterns seen as a part of, or extension to, these patterns - or are they seen as a separate collection?
FYI
I'm a solution architect who comes from a software development background, not an infrastructure one. When I say "infrastructure" I'm meaning stuff like networking, physical and virtual servers and their deployment architecture, capacity and volume planning, server and network security, and so on - basically anything that a "software" architect might rely on but not explicitly architect themselves.
Update - Definitions
Just for clarity for people reading this later:
"Patterns" is a broad term, which is not discipline specific...
In software engineering a software design pattern is a specific solution (much like a recipe) to a common code-level problem. These types of pattern are usually technology agnostic, but may be specific to a programming language paradigm (e.g. Object Orientated vs an alternative).
(System / Application) Architecture Patterns, cover common system-level architecture & design problems, including: internal component structure, component-level roles and responsibilities, cross-cutting aspects such as authentication and authorization, error handling and observability, data persistence.
