Principles and code style (draft)

Defining (architectural) principles and code style keeps the code base consistent and manages expectations for contributions.

Backend

On the backend, we use the Django framework and follow the project structure of having apps within the project.

  • Django apps contains models, views and API definitions. They group a logical part of the greater project which is loosely coupled to other apps.

    Tests are in the django app package. Split tests in logical modules, and try to avoid complex nesting structures.

  • All apps must go in the src/openorganisatie directory, which namespaces all the Open Organisatie code in the openorganisatie package. This prevents name conflicts with third party applications.

  • Application names should always be in plural form.

  • Settings go in openorganisatie.conf, which is split according to deploy environment:

    • dev

    • ci

    • staging

    • production

    • docker

    Settings must always be defined in the openorganisatie.conf.base with sane defaults.

  • Global runtime Open Organisatie configuration (database backed) should go in the openorganisatie.config app.

  • Generic tools that are used by specific apps should be a openorganisatie sub-package, or possibly go in openorganisatie.utils.

  • Integration with other, third-party services/interfaces should go in a openorganisatie.contrib package. This is currently (!) not the case yet.

  • Code style and imports are enforced in CI with ruff.