This post is a continuation of Unclean architecture.
From what I understand of Clean architecture it’s an iteration of Hexagonal architecture also known as Ports and Adapters (see the Wikipedia page).
OO is the ability, through the use of polymorphism, to gain absolute control over every source code dependency in the system. It allows the architect to create a plugin architecture, in which modules that contain high-level policies are independent of modules that contain low-level details. The low-level details are relegated to plugin modules that can be deployed and developed independently from the modules that contain high-level policies.
Martin, Robert C. . Clean Architecture (Robert C. Martin Series) (p. 47). Pearson Education. Kindle Edition.
As we have seen around functional programming there are many ways of dealing with dependencies.
Compare Impureim sandwich with the hexagonal/clean/ports and adapters architecture
The question then is if the domain is supposed to be free from external code so that you have only code that you yourself understand or if it’s supposed to only be code without external IO/side-effects?
A clean as in pure functional domain without IO will be:
In the same way as a clean architecture. There might be implicit dependency on DB, UI et.c. due to features or flows that implies such. We even have Mark Seemann argue that functional architecture is Ports and Adapters.
There are people that argue that there is no such thing as clean code.
The problem is that low level vs high level is not a clear enough concept.
It feels like what Robert Martin is trying to describe is the business domain code without other peoples code (except when you really trust it), without code for IO like http, file access et.c..
You could perhaps argue that when trying to come up with a clean architecture for Haskell then one way to define such a scheme could be to you isolate your business code from any IO (something quite feasible in Haskell). The benefit of using some of the functional programming concepts is that they at least have a formal definition that can be verified.
My guess is that the problem is that for many senior developers/programmers clean code is related to feelings of cleanliness, so will be apparent to programmers that have gotten a feeling for it (my guess being that you would teach that through literary workshops).
FP concepts have come to have a broad influence over many mainstream core frameworks (see the functional concepts in Java and C# base libraries). We can argue that these concepts give us tools and definitions that help remove the fluff around the definitions. The downside is that the language of functional programming is often unfamiliar and feels foreign to many developers (why it makes sense to use the concepts without explicitly mentioning them).
Do you want to send a comment or give me a hint about any issues with a blog post: Open up an issue on GitHub.
Do you want to fix an error or add a comment published on the blog? You can do a fork of this post and do a pull request on github.
Comments