From 05b4aa8d4b9b5358aac72bdbf65a138b1b87a44f Mon Sep 17 00:00:00 2001 From: Rebecca Graber Date: Mon, 6 Jun 2022 11:36:27 -0400 Subject: [PATCH] docs: ADR with guidance for new applications (#30053) --- docs/decisions/0014-no-new-apps.rst | 34 +++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 docs/decisions/0014-no-new-apps.rst diff --git a/docs/decisions/0014-no-new-apps.rst b/docs/decisions/0014-no-new-apps.rst new file mode 100644 index 0000000000..6c07a8e2c0 --- /dev/null +++ b/docs/decisions/0014-no-new-apps.rst @@ -0,0 +1,34 @@ +Justifying new Django applications in edx-platform +================================================== + +Status +------ +Accepted + +Context +------- +The Open edX platform is moving toward a more modular architecture. The goal is to transition from a monolithic application in edx-platform to one in which this repository represents a small, stable core with volatility pushed into extensions and plugins. To that end, much of the original edx-platform repository has been split out into micro-frontends, other microservices, plugins, and libraries. However, there are still a number of optional and non-core Django applications within edx-platform and new ones continue to be added. +For more information on plugins in particular, see the `Django Apps Plugin README`_. + +.. _Django Apps Plugin README: https://github.com/openedx/edx-django-utils/blob/master/edx_django_utils/plugins/README.rst + + +Decision +-------- +From the adoption of this ADR, no new Django applications should be added into the edx-platform repository without an accompanying ADR explaining why the application cannot or should not be created in a new repository or included in an existing external plugin or library. + +Further Guidance +---------------- + +While the preference should always be to develop outside the edx-platform repository, either by extending an existing external Django application repository or creating a new one, there are still acceptable reasons why a new application would be better developed within edx-platform: + +* The application relates directly to core functionality: course authoring, course administration, or learner-courseware interactions +* The application requires multiple imports from edx-platform + + * Note: There are strategies for plugging apps into core LMS and CMS behaviors without directly importing edx-platform code, notably the `Hooks Extension Framework`_. + * If it is truly necessary to import from edx-platform code directly, in addition to noting this in the ADR, the authors of the new application should add the libraries or applications it imports to the `Libraries we KNOW we want to move out of the monolith`_ Confluence page. + + +.. _Hooks Extension Framework: https://open-edx-proposals.readthedocs.io/en/latest/architectural-decisions/oep-0050-hooks-extension-framework.html + +.. _Libraries we KNOW we want to move out of the monolith: https://openedx.atlassian.net/wiki/spaces/AC/pages/525172740/Libraries+we+KNOW+we+want+to+move+out+of+the+monolith