Tech debt - service dao layers for api

[jordy2254]

Issue

The db is the core area passed throughout the code base. Nothing is currently broken away into segregation of layers. This poses the downside of everything being mixed together. In some places this is fine however in some places I've noticed it has lead to duplication or more confusing flows. For the long term stability and improvement of the product I'm suggesting to use the service & dao layered architecture.

Fix

Refactor (over time) and introduce new code guidelines to use the service dao layer for the application. commonly called service and repository in the go world. This doesn't need to be done overnight. Enforcing a coding standard going forward will lead to gradual refactorings over time. And areas which are less commonly touched can be broken out specifically in smaller chunks and PR's.

Benefits

Faster change, better centralization of logic easier to break away from the api in the future if ever desired.

[viktorstrate]

Sounds like a good idea, do you have any resources where we can read more about this architecture?

[jordy2254]

Hey Viktor
Here's a link thar summarises it well, https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch01.html

There also clean architecture that's similar but implements some other differing principals, this article seems to cover the basics, https://dev.to/eminetto/clean-architecture-using-golang-5791

I'd be suggesting using the closed service principal (if using a layered approach) where everything must pass through a service to get to the dao.

Googling layered architecture and clean architecture, willl lead you to many stack overflow, blog pages etc. about the subjecr