Error Kernel Pattern

2019 Unicorn enterprise heavily recruited Python engineer standard & GT; > >

Because I saw the word “Error Kernel Pattern” when looking at Akka’s materials, I wanted to check the meaning of the materials.
The concept of Error Kernel is introduced in Roland Kuhn’s Reactive Design Patterns book.
Let me translate this:

“In a supervisory hierarchy, keep important application state or functionality near the root directory while delegating dangerous operations to the leaves.”
This pattern, built on the Simple Component pattern, is suitable for combining components with different failure probabilities and reliability requirements anywhere in a larger system or application — some features of the system must never fail, while others must fail. Applying the simple component pattern usually puts you in this position, so you need to be familiar with the error kernel pattern.
This pattern has been built into The Erlang program for decades, and was one of JonasBoner’s main inspirings for implementing the Actor frame-Akka on the JVM. The name Akka was originally thought to be a palindrome from the Actor Kernel, referring to this core design pattern.

Since this pattern is designed according to the simple component pattern, translate what the author wrote.

“A component can only do one thing, but do it all.”
This pattern applies anywhere the system performs multiple functions, or it performs functions that are so complex that they need to be broken down into different components. An example is a text editor that includes spell checking: two separate functions (editing can be done without spell checking, and spelling can be done on finished text without editing), but on the other hand, these functions are simple.
The simple component pattern originates from the principle of single responsibility proposed by Tom DeMarco in his 1979 book “Structural Analysis and System Specification” (Prentice Hall). In its abstract form, it requires “maximizing cohesion and minimizing coupling.” Applied to object-oriented software design, it is generally stated as follows: “A class should have only one reason to change.”


Reproduced in:

Read More: