-
Notifications
You must be signed in to change notification settings - Fork 54
Domain Object Model
Manuel Meister edited this page Jan 2, 2023
·
6 revisions
On this page, a rough overview of the entity model is given. For better readability, the model was split into several sections. Each section shows the association model and provides a short description of each entity. For detailed documentation, please check the documentation provided in the source code of each entity class: https://github.com/ecamp/ecamp3/tree/devel/api/src/Entity
If you are not familiar with UML class diagram notation, check out any of the public available documentation on UML, e.g.
- https://en.wikipedia.org/wiki/Class_diagram
- https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-aggregation-vs-composition/
Entity | Description |
---|---|
User |
List of all users, including active users with an own login and inactive users (i.e. pending invitations) |
MailAddress |
Used to control verification of users' email addresses. |
Login |
Stores users' login credentials (e.g. password - yes, hashed and salted) |
UserIdentity |
Used to register any 3rd party authentication providers (e.g. Google, Facebook, etc.) |
Entity | Description |
---|---|
AbstractCampOwner |
Generalization class to ensure that both users and groups have the capability to own a camp. Only 1 party can own a camp at any given time. |
Camp |
List of all camps (incl. courses). Camps are connected to users in multiple ways: Each camp has a creator (User ); Each camp has an owner (User or Group trough AbstractCampOwner ); Each camp can have multiple users collaborating trough CampCollaboration
|
CampCollaboration |
Link table to allow collaboration of users in camps with different roles. |
User |
List of all users |
Group Post MVP |
List of all groups (=einzelne Pfadiabteilungen oder andere lokale Vereine). The list is organized in a tree structure (parent/children associations), with a few nodes on the top (=Dachverbände wie PBS) |
GroupMembership Post MVP |
Users can have different roles (e.g. member, manager) in groups trough the GroupMembership link table. |
Entity | Description |
---|---|
Camp |
List of all camps |
Period |
A camp can consist of different periods (=Teillager). These periods may currently not overlap, so they must be distinct (z.B. Vorlager und Hauptlager). Most camps will have 1 single period. |
Day |
Uses to store information connected to a single Day (e.g. Tageschef ) |
Activity |
Starting point for all content connected with a single activity (=Lager-/Kursblock). Note that the timing of an activity is not included in this entity but in ScheduleEntry. |
ScheduleEntry |
Responsible for the timing of activities. This allows the same activity to occur multiple times within the same camp without the need to hardcopy the content. |
Category |
Categorization of activities incl. color coding and adjustment of behavior and look&feel of the activity. Examples: Essen, Lagersport, Leitersitzung, etc. |
Entity | Description |
---|---|
Camp |
List of all camps |
Category |
List of all categories |
Activity |
List of all activities |
AbstractContentNodeOwner | Generalization class to ensure that both Category and Activity have the capability to own a ContentNode . It is a Root-ContentNode of a tree. |
ContentNode |
Each ContentNode defines some content. The kind of content is defined by ContentType . ContentNode can have Child-ContentNode s. It is a tree-structure. |
ContentType |
Defines the kind of content. Each ContentType can have it's own sub-entities (e.g. StorboardSection, SingleText). |
CategoryContentType |
Liste of prefered ContentType s to be used in a Activity
|
- Home
- Installation
- Domain Object Model
- API
- Design
- Localization and translations
- Architecture
-
Testing guide
- API testing (TBD)
- Frontend testing
- E2E testing (TBD)
- Deployment
- Debugging