DB refactor #1418
Labels
1. api
This issue/pr relates to an issue/change on the api
1. feature
New feature or request
2. backend
This issue/pr relates to an issue/change on the backend
discussion
Issue meant for discussion
hangar-team
Pre-discussed and well-made PRs might be approved, but is preferably done by collaborators
help wanted
Extra attention is needed
the current DB structure is a mess and causes our queries to be a mess which causes everything to be slow and makes changes hard.
I propose completely wiping the DB and starting from scratch (while obviously migrating data over, most likely by having a new DB in postgres and setting hangar into read only while migration happens).
while that obviously seems super dauting and a giant task, I propose refactoring the backend to adhere to domain driven development (DDD) principles, basically splitting everything up into domains (users, projects, versions, pages, jobs, etc) and giving each domain ownership over its tables.
then we can rewrite stuff one by one.
ideally, the domains only expose domain objects, not DB objects, so internal changes in a domain in the future will have no affect on other domains.
I envision a facade infront of a each domain that will only expose strictly typed interfaces.
so a VersionFacade would have a methods getVersion()Version, getVersionWithDependencies()VersionWithDependencies, getVersionWithPlatforms()VersionWithPlatforms, getVersionFull()FullVersion etc., all backed by an internal VersionImpl class that has all these fields.
The facade could also implement all security stuff (if that isnt done in the db queries) and hiding certain fields for certain callers (i.e. IDs shouldn't be exposed in the public api)
list of "requirements":
The text was updated successfully, but these errors were encountered: