Gary Bernhardt describes a similar architecture using a "Functional Core, Imperative Shell" in his Boundaries talk[1].<p>"Purely functional code makes some things easier to understand: because values don't change, you can call functions and know that only their return value matters—they don't change anything outside themselves. But this makes many real-world applications difficult: how do you write to a database, or to the screen?"<p>"This design has many nice side effects. For example, testing the functional pieces is very easy, and it often naturally allows isolated testing with no test doubles. It also leads to an imperative shell with few conditionals, making reasoning about the program's state over time much easier."<p>[1] <a href="https://www.destroyallsoftware.com/talks/boundaries" rel="nofollow">https://www.destroyallsoftware.com/talks/boundaries</a><p>[2] <a href="https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell" rel="nofollow">https://www.destroyallsoftware.com/screencasts/catalog/funct...</a>
> <i>Free monads permit unlimited introspection and transformation of the structure of your program; Free monads allow minimal specification of each semantic layer, since performance can be optimized via analysis and transformation.</i><p>That is not true and this overselling of the Free monad is hurting the concept.<p>The Free monad is nothing more than the flatMap/bind operation, specified as a data-structure, much like how a binary-search tree describes binary search. And this means an imposed ordering of operations and loss of information due to computations being suspended by means of functions.<p>You see, if the statement I'm disagreeing with would be true, then you'd be able to build something like .NET LINQ on top of Free. But you can't.
I'd not say this is a feature of functional programming. This is a feature of Object Oriented elements being included in fp languages.<p>These are the same things we were going to happen when using Java and C++ years ago.<p>You can even see similar graphics here: <a href="https://docs.oracle.com/javase/tutorial/java/concepts/object.html" rel="nofollow">https://docs.oracle.com/javase/tutorial/java/concepts/object...</a><p>I remember there was another in this tutorial that shared more with the image in this post. Although this is the same idea. You're just hiding Objects in Objects.
Unrelated to functional programming there is Onion Architecture defined by Jeffrey Palermo in 2008 which I find a very nice and simple way to architect/organize a LoB application.<p><a href="http://jeffreypalermo.com/blog/the-onion-architecture-part-1/" rel="nofollow">http://jeffreypalermo.com/blog/the-onion-architecture-part-1...</a>
<a href="http://jeffreypalermo.com/blog/the-onion-architecture-part-2/" rel="nofollow">http://jeffreypalermo.com/blog/the-onion-architecture-part-2...</a>
<a href="http://jeffreypalermo.com/blog/the-onion-architecture-part-3/" rel="nofollow">http://jeffreypalermo.com/blog/the-onion-architecture-part-3...</a>
<a href="http://jeffreypalermo.com/blog/onion-architecture-part-4-after-four-years/" rel="nofollow">http://jeffreypalermo.com/blog/onion-architecture-part-4-aft...</a>
How does this architecture constrast with Rust? Has anyone built anything like this in Rust?<p>It makes me think of an article where the author tries to abstract the implementation of IO from the the domain logic. [1]<p>[1] <a href="https://blog.skcript.com/asynchronous-io-in-rust-36b623e7b965" rel="nofollow">https://blog.skcript.com/asynchronous-io-in-rust-36b623e7b96...</a>