Post-alpha refactoring

[kislerdm]

Followup on the conversation.

Problem

The codebase feels over-complex for the amount of actual logic it carries. Moreover, it lacks unit test and clear separation of logic and interfaces. For example, the logic which assesses the provider's info is coupled to repositories which makes unit testing convoluted and code maintenance hard.

Proposed solution

• Follow "port-adapters" pattern
• Separate concerns: SerDe+adapter of the provider/module's attributed from I/O and caching layer, and from downstream pipeline (2nd lambda trigger)

[cube2222]

Thanks for creating the issue @kislerdm!

It's a fair point, though right now we don't even know if the registry will stay with us post-alpha.

Basically, once the alpha release is out, we'll post issues to discuss what approach we want to take for the stable release. I'd hold off with refactoring this repo until we've actually chosen this approach to stay (if that even happens).

[kislerdm]

@cube2222 Hey Kuba! Thanks for coming back on the matter. 100% with you on holding any refactoring until we have a decent bet on how we will move forward with the registry implementation post alpha. For clarity, this issue was meant as placeholder to initiate "formal" alignment on registry post-alpha.