From 6a8344b18e0c4966ed0c534773162767c71122ad Mon Sep 17 00:00:00 2001 From: Arve Knudsen Date: Tue, 16 Mar 2021 10:49:01 +0100 Subject: [PATCH] Docs: Document backend package hierarchy model (#31930) * Docs: Document backend package hierarchy model Signed-off-by: Arve Knudsen --- .../architecture/backend/package-hierarchy.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 contribute/architecture/backend/package-hierarchy.md diff --git a/contribute/architecture/backend/package-hierarchy.md b/contribute/architecture/backend/package-hierarchy.md new file mode 100644 index 000000000000..47daab6aa578 --- /dev/null +++ b/contribute/architecture/backend/package-hierarchy.md @@ -0,0 +1,16 @@ +# Package hierarchy + +The Go package hierarchy in Grafana should be organized logically (Ben Johnson's +[article](https://medium.com/@benbjohnson/standard-package-layout-7cdbc8391fc1) served as inspiration), according to the +following principles: + +* Domain types and interfaces should be in "root" packages (not necessarily at the very top, of the hierarchy, but + logical roots) +* Sub-packages should depend on roots - sub-packages here typically contain implementations, for example of services + +## Practical example + +The `pkg/plugins` package contains plugin domain types, for example `DataPlugin`, and also interfaces +such as `RequestHandler`. Then you have the `pkg/plugins/managers` subpackage, which contains concrete implementations +such as the service `PluginManager`. The subpackage `pkg/plugins/backendplugin/coreplugin` contains `plugins.DataPlugin` +implementations.