It is not a coincidence they are similar. Since Bernhardt says the "functional core, imperative shell" concept is inspired by Ports & Adapters, and essentially boils down to it, but simply on a lower level: dealing with functions, not services.
Boundaries / “Functional Core, Imperative Shell” - 2012, Gary Bernhardt, the same principle as Ports & Adapters, but on a lower level, and using FP: isolating the business logic in a functional core (pure, immutable), and interact with the outside world (impure, mutable) in an imperative shell.
“Separating the stateful parts of my program from the functional parts.”ref
“The shell is really an adapter between the functional core and the nasty external work. I’m just building adapter after adapter inside the imperative shell, to hide the external world from my functional code. In a large system, you don’t have one giant shell and one giant core; that would become a mess. What you have is lots of small functional cores, and lots of imperative shells wrapping them, communicating probably via messages. If you know the Actor Model, I’ve pretty much described it. Because that is the Actor Model.“ref
So he ties "Functional Core, Imperative Shell" to Ports & Adapters but even also to the Actor Model. But notably he doesn't envision one giant shell and one giant core.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It is not a coincidence they are similar. Since Bernhardt says the "functional core, imperative shell" concept is inspired by Ports & Adapters, and essentially boils down to it, but simply on a lower level: dealing with functions, not services.
Boundaries / “Functional Core, Imperative Shell” - 2012, Gary Bernhardt, the same principle as Ports & Adapters, but on a lower level, and using FP: isolating the business logic in a functional core (pure, immutable), and interact with the outside world (impure, mutable) in an imperative shell.
“Separating the stateful parts of my program from the functional parts.” ref
“The shell is really an adapter between the functional core and the nasty external work. I’m just building adapter after adapter inside the imperative shell, to hide the external world from my functional code. In a large system, you don’t have one giant shell and one giant core; that would become a mess. What you have is lots of small functional cores, and lots of imperative shells wrapping them, communicating probably via messages. If you know the Actor Model, I’ve pretty much described it. Because that is the Actor Model.“ ref
So he ties "Functional Core, Imperative Shell" to Ports & Adapters but even also to the Actor Model. But notably he doesn't envision one giant shell and one giant core.