A cleaner architecture for Argopy

[gmaze]

Why ?

With Argopy growing in size and diversity in terms of primary objects exposed to users (eg: DataFetcher, ArgoFloat, ArgoIndex, ArgoNVSReferenceTables, ArgoDocs, ArgoDOI, ArgoColors, etc...), I am more and more concerned about the library architecture.

Argopy has been maintained for the last 5 years and this task won't be an issue for a while.
We already adopted a lot of good practices and the current architecture is robust.

But there's always room for improvement.
And in particular, I'd like to make it as easy as possible for new contributions to the codebase to arise.
To achieve this, I believe a clean architecture is the best start.

So I create this discussion as a somehow prospective thread, turned toward software architecture lovers.

[gmaze]

First thoughts

Watching this talk: https://www.youtube.com/watch?v=qDTi1h3-Rvs by Leonardo Giordani is inspiring to me.

The talk discusses how components are connected and how to lower coupling between different parts of a system, to avoid creating software that cannot easily be maintained or changed

In particular the layer structure as

a way of structuring applications that leverages layers separation and internal APIs to achieve a very tidy, fully-tested, and loosely coupled system.
with communication between layers going inward with simple structures and outward with interfaces
is a nice framework to look at the Argopy codebase.

I see some of this design already implemented in Argopy, notably the dependency injection (of what we call stores, like the httpstore).

But some Argopy objects probably belongs to more than one layer in such a design.
ArgoFloat for instance can be considered in the Use cases layer, but also as Gateways.

[gmaze]

The "clean architecture" is further explained in this blog post:

https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html