IntenseWebs/grafana
3
0
Fork 0
mirror of https://github.com/grafana/grafana.git synced 2024-12-28 01:41:24 -06:00
Code Issues Packages Projects Releases Wiki Activity

Docs: Document backend package hierarchy model (#31930)

Browse Source 
* Docs: Document backend package hierarchy model

Signed-off-by: Arve Knudsen <arve.knudsen@gmail.com>
This commit is contained in:
Arve Knudsen 2021-03-16 10:49:01 +01:00 committed by GitHub
parent cbaf700d64
commit 6081c00119
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 16 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
contribute/architecture/backend/package-hierarchy.md Normal file
View File

@ -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.