Refactoring service/db layers

opqdonut commented 4 years ago

some notes by @opqdonut @Macroz about possible ideas

[ ] decide about plurals. Now we have rems.db.form but rems.db.licenses and rems.services.attachment but rems.db.attachments
[x] create missing rems.services.form (#2180)
[ ] unify ids, now we have for example :id, :licid and :license/id. Return :license/id already from the db.
[ ] unify ids, now we have for example :wfid, :catid etc. Prefer :workflow/id and :catalogue-item/id or something.
[ ] decide where to join the related entities i.e. the responsibilities between the levels should be clear (i.e. where do you join/enrich the license of resource and organization of license?), who formats for internal and who for API?
[ ] db.applications uses all the other db namespaces and probably the functionality is at the wrong level
[ ] decide where to cache stuff and do it one way for everything
[ ] document decisions in architecture docs / ADR
TODO more

Macroz commented 4 years ago

Ideas: we can for example decide that

each db ns can only use db.core, will introduce a common internal format with all data, has helpers for making things easy for services
each service ns can combine db namespaces but not services, will compose db functions into straightforward functions for api layer, will format the data according to API use, will handle access rights and information hiding, will join related concepts
each api namespace handles compojure-api and swagger concerns and calls service layer
the new dependency system should serve the service layer especially
some caching could be in db layer, but since service layer does a lot of joining and formatting, some can be added there too but I think we can scale the application servers easier than db if need be

Macroz commented 2 years ago

CSCfi / rems