How to Make Design Patterns to Meta Patterns learn architectural patterns

architectural patterns | Design Patterns | Meta Patterns

adminMay 12, 2022

2 395 8 minutes read

For the last month or two, I’ve been researching all kinds of patterns: design patterns, architectural patterns, container patterns, some other domain-specific patterns (such as parallel computing patterns), and so on.

After buying books, reading papers, and reading codes, I found that my understanding 
of patterns was not deep enough. Therefore, this article is used to record some of 
the lack of things, such as pattern languages, patterns of patterns, etc.

PS: For the convenience of reading, the title of this article is in shorthand mode, and the full name is in the last related materials.

modal renegotiation

In order to avoid questions like Datum is the best language, before that, I have to say something about patterns:

A pattern is a summary of the idiomatic way, not limited to programming. Quite a few people are used to using various design patterns, but they don’t know what kind of pattern it is. It is a concept word list for quick communication.
The pattern is the solution, the hammer’s law, and you only need it when you have a specific problem.
Modes are suitable for specific scenarios. Most modes are useless for the current system, and often only a few modes are suitable.
The pattern is the presentation of the knowledge system. How many patterns are mastered and more knowledgeable do not necessarily represent the real code level and ability.
Patterns need to be deliberately practiced. Learning patterns is a long process, so you will always encounter problems of understanding, solving, and using errors. Don’t worry.
There are many kinds of patterns, and the computer industry generally agrees that the origin of patterns is Alexander’s “The Eternal Way of Architecture”. There are also corresponding summaries in earlier times, but here are the most systematic techniques.

In addition to design patterns, there are a ton of other patterns in our industry:

Container design patterns. In response to a series of complex fractional scenarios under cloud-native applications, Google’s engineers published related papers to summarize them, such as Sidecar, Adapter, Ambassador, etc.
Architectural Patterns. Architectural patterns are generic, repeatable solutions to common software architecture issues in a given context. In addition, some common architectural styles, such as microservices, event-driven architecture, etc., are also classified into architectural patterns in terms of general categories.
…

So, you’ll find that these patterns are just summaries of people’s idioms.

look for patterns

Looking back, when we find that we have entered a new field and carried out the architectural design in related fields, we will continue to search for various kinds of data, and then fit them into the design. In fact, we are looking for patterns in the field, with these patterns, we can design a system like a cat and a tiger without too many problems.

With any luck, we can even do better than most people in the field — because what we have is a model for solving this type of problem.

At this time, we already have a very advantageous routine to help us better enter new areas. However, as a newcomer to a new field, I often do not know which model should be adopted, nor what kind of relationship exists between the models.

Related Books: Design Patterns

Schema classification: catalog, collection, warehouse

In a software system, patterns rarely exist independently, and often multiple patterns are combined with each other to solve specific problems. One of these organizational patterns is pattern collections. Then, according to different needs, they are divided into categories. Several ways as introduced in “POSA 5”:

Ad hoc organization.
According to the level of division: according to the level of abstraction, granularity, and scale.
Organized by field: telecommunications, finance, e-commerce, etc.
Organize according to partition: which part of the architecture belongs. Such tiers, tiers, components, and packages are examples of partitions
Organize according to intent: such as POSA, 23 design patterns of GoF, DDD
…

Next, let’s look at a few classification examples.

Organization of Design Patterns

The concepts introduced in the book Design Patterns are “design pattern spaces,” which are grouped into three categories:

Singleton pattern, abstract factory pattern, builder pattern, factory pattern, and prototype pattern are examples of creative patterns.
Adapter pattern, bridge pattern, decorating pattern, composition pattern, appearance pattern, flyweight pattern, and proxy pattern are examples of structural patterns.
Template method pattern, command pattern, iterator pattern, observer pattern, mediator pattern, memorandum pattern, interpreter pattern, state pattern, strategy pattern, responsibility chain pattern, and visitor pattern are some examples of Behavioral patterns.

The two criteria for its division are the purpose criterion, which is used to accomplish what works; the scope criterion, whether the specified pattern is used for a class or an object.

Organization of DDD

The book Domain Driven Design is also a collection of patterns, which is one of the reasons why this book is not easy to read. Another reason is that the people who translated the book did not understand well what a unified language was.

In the book “Domain-Driven Design”, the pattern is organized in various forms, and the four parts, in turn, are (PS: personal temporary summary):

Using Domain Models – “Patterns for Model Knowledge Extraction”
The Building Blocks of Model-Driven Design – “Patterns of Model Design”
Deepen understanding through refactoring – “Model Optimization Patterns”
Strategic Design – “Model Boundary Demarcation Mode”

And this order is actually our design process in the process of implementing DDD, and then we carry out hierarchical organization. For example, the “Strategic Design” part is divided into different collections according to different intentions:

Maintain model integrity, such as bounded contexts, context maps, etc.
Refinement: core domain, general domain, etc.
Large-scale structures: Evolving Order, system metaphors, etc.

Therefore, from a structural point of view, “Domain-Driven Design” is a book from small to large, which is slightly more difficult to read and requires certain experience.

The intent of pattern classification

We regard “how to apply design patterns as a problem domain”, then pattern classification is a solution in this problem domain.

In different complex fields of computer, such as parallel programming, architecture design, etc., they themselves contain a large number of patterns. And with further classification of these patterns, it will be more helpful for us to apply patterns – at least when dealing with the same sub-problem, we can look for possible alternative patterns.

However, most of the time, what we often don’t know is: what is the problem we have?

Pattern language in the corner

As defined in “POSA 5”: Pattern languages are highly relevant to specific fields, and can provide specific and comprehensive guidance for this type of system, including the following:

What are the main problems to be solved?
In what order should these issues be addressed?
To solve a given problem, what alternative solutions are available?
How do deal with dependencies between problems?
What is the most effective way to solve a single problem when there are “peripheral” problems?

In short, a pattern language abstracts patterns for a specific problem (such as parallel programming) and includes the relationships between them, which can be used to solve this type of problem systematically.

The book also mentions Gerard Meszaros’ point that “pattern languages can be used to guide beginners in creating systems”. Aha, isn’t that what we want? As a newcomer entering a new field, we need such a pattern language. While a pattern language can help us with this type of problem, it also means it needs to be: adequate coverage, sustainable progress, and tight integration. Following this set of premises, it means that those who design the pattern language should be experts in the industry and that the patterns themselves should be constantly evolving.

So while we see how to implement and use patterns as our problem, then pattern languages solve patterns for this class of problems.

Pattern Language for Distributed Computing

The “POSA” series is probably the best information we can find in the Chinese world. Therefore, here again, take “POSA 4” as an example. “Pattern-Oriented Software Architecture: A Pattern Language for Distributed Computing” is the full name of “POSA 4”.

Let’s first look at the diagram (the circle in the diagram represents the problem domain, the continuous representation is their relationship, and each problem domain contains related patterns):

For example, “From Mud to Structure” at the beginning is a large problem domain, and corresponding to this problem domain, it contains a series of patterns, such as MVC, layering, PAC, microkernel, etc. At the same time, for this problem, if we also need database access, then we obtain the corresponding schema from the database access to improve our design.

Then, after we get to the specific pattern/problem domain, it also details how to implement the corresponding pattern. Such as layering:

With the cooperation of this series, we can perfect the design of the whole system.

A pattern language for microservices

Next, let’s take a look at the microservice architecture pattern overview in “Microservice Architecture Design Patterns”:

From the figure above, we can see that this microservice pattern language, organized by Chris Richardson, categorizes the languages in multiple layers and indicates the relationship between them. It is a pity that this schema language only contains relationships, and lacks some descriptions of related relationships.

Even so, in general, it can help us design microservices to a certain extent.

Related books: “POSA 4”, “POSA 5”, “Microservice Architecture Design Patterns”

pattern of patterns

From pattern to pattern classification, to pattern language, we already have a whole set of solutions. Finally, we are left with some interesting questions, such as how to discover new patterns? How to do some abstraction of the existing schema.

The understanding of “pattern of patterns” helps us to better understand design patterns. After understanding the design pattern, you only need to understand the pattern behind it, and you don’t need to memorize each design pattern.

So, we came to the element pattern, which is also based on the book “Element Pattern”.

Element Patterns: Patterns for Design Patterns

Patterns are derived from summarizing idioms, while elements such as element patterns are abstractions of design patterns, that is, patterns within patterns. The core concept of Elemental Design Patterns is a set of basic object-oriented concepts.

Breaking down the design patterns in OO more finely, we get the patterns behind them. As one of the core element patterns are: object creation, retrieval, inheritance, and abstract interface. So, as the book says, by combining this four EDPs, we can create pairs, enforce specific guarantees, establish associations from this at runtime, create other types from one type, create declarations, and Comes with a future, unspecified type of warranty.

When we implement method calls, we also abstract four EDPs: recursion, delegation, redirection, and aggregation, which constitute the building blocks of the design.

the pattern of architectural patterns

Finally, back to the question I want to abstract, what is the pattern behind the architectural pattern? I tried a simple teardown:

contract. Input and output, API, etc.
segmentation. Isolate changes, clarify responsibilities, etc.
constraint. Functional and non-functional requirements, performance, etc.
package. Interface encapsulation.
cooperation. Collaborative style, etc.
…

Of course, I also need them to be renamed to build a unified language in the field of architectural patterns.

other

Although it is a bit complicated, the basis is interesting.

Relevant information

“Elemental Mode”
“Design Patterns” -> “Design Patterns: The Foundation of Reusable Object-Oriented Software”
“POSA 4” -> “Pattern-Oriented Software Architecture, Volume 4: Pattern Languages for Distributed Computing”
“POSA 5” -> “Pattern-Oriented Software Architecture, Volume 5: Patterns and Pattern Languages”
“Domain-Driven Design” -> “Domain-Driven Design: Coping with the Complexity of Software Core”