Quite a lot of different people have been on the same trail of thought. Gary Bernhardt's formulation of a "functional core, imperative shell" seems to be the most voiced.
"Imperative shell" that wraps and uses your "functional core".. The result of this is that the shell has fewer paths, but more dependencies. The core contains no dependencies, but encapsulates the different logic paths. So we’re encapsulating dependencies on one side, and business logic on the other side. Or put another way, the way to figure out the separation is by doing as much as you can without mutation, and then encapsulating the mutation separately. Functional core — Many fast unit tests. Imperative shell — Few integration tests
https://www.youtube.com/watch?v=yTkzNHF6rMs
https://www.destroyallsoftware.com/talks/boundaries
https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell
All code can be classified into two distinct roles; code that does work (algorithms) and code that coordinates work (coordinators).
https://simpleprogrammer.com/2012/10/21/there-are-only-two-roles-of-code/
Great talk, but specifically on the separation of side-effects at the at the 27 minutes 53 seconds mark.
https://realm.io/news/andy-matuschak-controlling-complexity/
Interpreters of the functional core
http://degoes.net/articles/modern-fp
http://degoes.net/articles/modern-fp-part-2
Hexagonal Architecture is an architecture defined by establishing a perimeter around the domain of your application and establishing adapters for input/output interactions. By establishing this isolation layer, the application becomes unaware of the nature of the things it's interacting with.
Create your application to work without either a UI or a database so you can run automated regression-tests against the application, work when the database becomes unavailable, and link applications together without any user involvement.
http://alistair.cockburn.us/Hexagonal+architecture
https://github.com/jschairb/sandbox/wiki/HexagonalArchitecture
Growing Object-Oriented Software, Guided by Tests Without Mocks - Vladimir Khorikov
http://enterprisecraftsmanship.com/2016/07/05/growing-object-oriented-software-guided-by-tests-without-mocks/
Test Isolation Is About Avoiding Mocks - Gary Bernhardt
https://www.destroyallsoftware.com/blog/2014/test-isolation-is-about-avoiding-mocks
To Kill a Mockingtest - Ken Scambler
http://rea.tech/to-kill-a-mockingtest/
Mocking is Tautological - Mark Sands
http://marksands.github.io/2014/05/14/mocking-is-tautological.html
"Functional core & Imperative shell" : OO design, and isolated tests without mocks
http://blogs.perl.org/users/mascip/2014/06/functional-core-imperative-shell-oo-design-and-isolated-tests-without-mocks.html
http://blogs.perl.org/users/mascip/2014/06/functional-core-imperative-shell-explanation-with-code.html
Business-Friendly Functional Programming, Part 2: Testability - Yang Bo
http://rea.tech/business-friendly-functional-programming-part-2-testability/
mokacoding - unit and acceptance testing, automation, productivity
http://www.mokacoding.com/blog/functional-core-reactive-shell/
Functional Core, Imperative Shell - Sean Hammond
http://www.seanh.cc/posts/functional-core-imperative-shell
BoochTek, LLC
http://blog.boochtek.com/category/programming/architecture
Functional Programming in Ruby - Vitor Capela
https://speakerdeck.com/dodecaphonic/functional-programming-in-ruby
Enemy of the State by Justin Spahr-Summers
https://speakerdeck.com/jspahrsummers/enemy-of-the-state
Functional Programming in Swift - slide 55+
http://www.slideshare.net/SaugatGautam2/functional-programming-in-swift
Test-Driven Development with Python - Harry Percival
https://books.google.dk/books?id=fTLJAwAAQBAJ&pg=PA403&lpg=PA403&dq=%22functional+core%22+%22imperative+shell%22&source=bl&ots=A4g25w7wWY&sig=x0bu4NZWiXrpzWPziAH7Y78AKgM&hl=en&sa=X&ved=0ahUKEwi0jq3em-zPAhUqG5oKHYNJBIE4ChDoAQhRMAk#v=onepage&q=%22functional%20core%22%20%22imperative%20shell%22&f=false
programming, when stripped of all its circumstantial irrelevancies,
boils down to no more and no less than very effective thinking so as to avoid unmastered complexity,
to very vigorous separation of your many different concerns.
-- Dijkstra EDW512
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD05xx/EWD512.html