-
-
Notifications
You must be signed in to change notification settings - Fork 166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FR] Architecture improvements #516
Comments
I believe the business layer should be able to import from app.models (if only to type the methods arguments). The business layer should not concern itself with persistence details, but still manipulates business objects which are described in app.models. |
An alternative to moving up permissions checks from the business layer into the blueprint layer, would be to have them only in the business layer (that is remove checks that are performed in the REST endpoints annotations) |
We should add issues to clean up the forbidden imports described in the architecture.md file and currently in violation. |
Should |
We should really rename app.datamgmt into app.persistence: it clearer. |
Moving up permissions_check_current_user_has_some_case_access_stricter ended up into into endpoints /case/report/generate-activities/int:report_id and /case/report/generate-investigation/int:report_id. Shouldn't these endpoints rather be annotated with @ac_api_case_requires(CaseAccessLevel.read_only, CaseAccessLevel.full_access)? |
Should permissions and PermissionDeniedError be moved up into the blueprint namespace? |
This issue is about the future improvements to be made on the architecture.
- blueprints : conversion from the public API to business objects (REST, GraphQL, flask templates)
- business : work in memory with business objects (should not have adhesion with app.model, should not have adhesion with db from app )
- datamgmt : persistence, adhesion with the database
The text was updated successfully, but these errors were encountered: