gossamer icon indicating copy to clipboard operation
gossamer copied to clipboard

refactor: Decouple database package from the core logic

Open EmilGeorgiev opened this issue 1 year ago • 1 comments

Issue summary

The package database is used around 120 times in the core logic. It's generally not a good idea to tightly couple your core business logic with external dependencies, such as database packages. The primary reasons are to enhance maintainability, testability, and flexibility. Currently there is an interface Database that can have multiple implementation, but If you decide to switch to a different database package or storage solution, it will requires significant changes to the core logic. Also there are other types and constants that are also used inside core logic. Here are some key points:

  1. Maintainability: - Loose Coupling: Keeping your core logic decoupled from external dependencies makes it easier to change or upgrade those dependencies in the future without having to rewrite your core logic. - Abstraction: Using interfaces or abstraction layers allows you to swap out implementations without affecting the rest of your application.

  2. Flexibility: - Future Changes: Abstracting database interactions allows you to switch databases or change your data storage approach with minimal changes to your core logic. - Multiple Databases: In some cases, you might need to support multiple databases or data sources. Decoupling your core logic from specific database implementations makes this much easier.

Recommended Approache

Declare local interfaces that abstract logic behind its implementation. By this way the core logic will not depend from external package and the implementation can be changed easy.

EmilGeorgiev avatar May 25 '24 15:05 EmilGeorgiev

If you think this makes sense, can I take this issue?

EmilGeorgiev avatar Jun 08 '24 14:06 EmilGeorgiev