An abstraction is "conceptual process where general rules and concepts are derived from the usage and classification of specific examples" wikipedia. A principle is a "proposition or value that is a guide for behavior or evaluation" wikipedia. I use the term pattern here as "the re-usable form of a solution to a (design) problem" (see also wikipedia).

Using abstraction and principles and patterns can be necessary (for instance in object-oriented software development to deal with its underlying deficiencies), but is generally very helpful. Quite often, applying the right set of them will help minimizing discontinuities avoiding cumbersome solutions. They are based on science, provided by some sort of authority, developed by best common practice (of a community or in some context), or selected using common sense and experience. Except for the scientific origin, hardly every will we find an explanations why those and not others are important. We can also find the negative, for example anti-patterns, See for instance wikipedia or this discussion on stackoverflow.

Here are a few things that I consider fundamental, based on my experience in science, research, and development. A lot of references and further discussion can be found in my research notes on Introduction to Network Architecure, see site and skb-web for details.

When looking at patterns, the best starting point is the work of Christopher Alexander, A Pattern Language (1977) and The Timeless Way of Building (1979). For networks, look at John Day’s Patterns in Network Architecture (2007). More recently, there is an interesting book by Jason McColm Smith called Elemental Design Patterns (2012). See rn-ina for more details.

This is fundamental. Everywhere. Not just in networks or software development. Its origin is in operating systems, namely by Hansen (Nucleus), and Wulf and Levin (Hydra) - see rn-ina for more details.

This abstraction (or principle) addresses the often essential problem, which is variance, not complexity. Using the principle (or abstraction) of separating mechanism from policy can (usually does) help to minimize variance. It does not necessarily minimize complexity.

To avoid reudctio ad absurdum, we can use a simple guideline: a mechanism focuses on the purpose (of something) and policies focus on ways to realize it. The goal then is to maximize invariance (mechanisms) and to minimize variance (policies). We need to look at commonalities and maximize them, thus reducing OPEX and CAPEX while improving management. Again, minimizing discontinuities also helps to avoid cumbersome solutions.

Use it wherever you can!

For me, these principles are fundamental. They are invented most and described all by Robert Martin, better known as Uncle Bob (wikipedia). There are five of them, as the abbreviation already suggests (wikipedia):

These principles can be applied to more than just software development!

Principles that help to properly organize classes in larger systems wikipedia. Or text fragments into larger document. Or …​ so they are actually more fundamental, imho. These principles come in twpo groups with three members each:

Every time we solve a problem it is related to a particular domain. These domains tend to come with their own context and models and terminology, or even taxonomy. The concepts of Domain-Driven Development (DDD) and Domain-Specific Languages (DSL) try to provide abstractions and more importantly patterns.