-
Notifications
You must be signed in to change notification settings - Fork 0
DDD: Entities
Collyn Brenner edited this page Jan 23, 2026
·
20 revisions
This pages lists and describes the Entities of the QuizStuff.com DDD domain.
In Domain Driven Design (DDD), 'entites' are data objects within the domain of the system that persist over time and which have a unique identity. For this reason every entity has an ID field/column that uniquely identifies it in its database table.
To learn more about DDD you can read "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans.
- The latest API documentation can be found in {root}/docs/QView API Documentation.docx
- There is a field called "built_including_tests" that tracks the progress of each endpoint's implementation in the backend API (true/false).
- Integrations tests are housed under {root}/backend/tests
- It is highly recommended to use TDD (Test-Driven Development) when adding API endpoints. We need all endpoints to have a high-level sanity check via integration tests that each respective endpoint works the way it is intended to. We can add other tests later if deemed useful or necessary.
- Unit tests will be found at the end of the code file for the code the unit test(s) test(s).
- If you add endpoints along with the corresponding integration test(s), make sure to update/add the corresponding endpoint to this documentation in your commit.
- This is someone who can log into QView. All Users have login information; there are NO records in this table that do not have login credentials.
- Access for each User is determined by processes which save data in various locations. The short and sweet of it is: Anyone can take-on any role. The idea behind this is to (1) create a universal experience while logged into QView, and (2) allow anyone to jump into any role (and perhaps encourage Users to do so by the mere visual of being able to, say, create a Tournament (if the User is normally a coach) or create a Team (if the user had only ever been a quizzer before and has now aged-out of quizzing)).
- Some examples of User access controls:
- An 'administrator' is either someone who created a Tournament or a User who has been made an Administrator of a Tournament by the creator of the Tournament (for instance, a tech team member/statistician). We may come to find that the admin who is the director of a the Tournament may wish to have control over what other admins have access to, which would then introduce some kind of permissions mechanism and probably the introduction of more specific roles. For now, we trust all Admins to not mess with the Tournament details.
- A 'quizzer' is a User (who may or may not have logged into QView before) assigned to a specific Team as a quizzer for that Tournament.
- A 'coach' is a creator of a Team or a User who has been assigned to be a Team's coach by another User who created the Team (typically the coach or program leader).
- The 'quizmaster' and 'contentjudge' are used as not-required references in each Game record.
- An 'equipment owner' is the person who registers the equipment to be used at a Tournament.
- For Registration. This a purely a convenience Entity - but a big convenience. A coach (who is a User) creates a list of Users who are quizzers for the purpose of re-usability for entering teams in multiple Tournaments as time goes on.
- The Roster is owned by a single coach as the Roster's primary coach.
- A coach can create a Roster and share it with other people who may be the coach of a certain Team in a certain Division at a certain Tournament. This allows that User to register using the same Roster of quizzers and adding themselves as the coach of the Team. Alternatively, the primary coach of the Roster can associate other Users as people who have been coaches for that Roster in the past or who will be coaches of Teams in the future, making for ease of access in finding those coaches over time.
- Purpose: A grouping for computing statistics across multiple Tournaments.
- Primary Use Cases: District quiz seasons and Tournaments that happen on an annual basis.
- The quiz event. This is one of the primary way users will navigate QView to find current stats for an event they are interested in.
- Purpose: Group quizzers of the same experience level so that newer quizzers are not discouraged by the level of competition more experienced quizzers quiz at.
- Most common values: "Experienced" and "Novice"
- A set of Games that all are scheduled to happen in the same timeframe.
- Used for scheduling questions per Round. Added via spreadsheet import if a Tournament Admin wants to import the scheduled Questions for record keeping. It would be useful to be able to export the questions too. Both formats should probably be acceptable (CSV and RTF).
- This table ensures all questions are unique, and so if a question is being imported and it is a duplicate of another based on content, then the existing reference is assigned to the Round instead of creating a new QuestionsAndAnswers record.
- Future plans are also open to housing QuizStuff questions that are not created by SetMaker admins. Plans for how this is to be implemented are still be fleshed-out.
- Rooms are grouped at the Tournament level so that a Tournament has multiple rooms. This allows for a Room to be used across Divisions within the same Tournament.
- This is the 2-team or 3-team match-up of 20 questions.
- This entity holds references to exactly one of each of the following (for data processing efficiency): Tournament, Division, Round, Room
- Could also be considered a "ScoreEvent" or "GameEvent"
- Each QuizEvent has a Type which defines the contexts for what event has taken place and what to do with the rest of the data in the event.
- This is sent from QuizMachine to QView (QMServer) one-by-one, where the 2nd QuizEvent is not sent until the web server confirms that it has received the 1st QuizEvent for that Game.
- While stats will be able to be generated based on data relationships of a number of other entities (like TournamentGroup, Tournament, Division, Round, Room), the StatsGroup provides a way to select specific Games to include in a custom stats set that is saved and which can be shared or revisited.
- A quiz team composed of 1 to 6 quizzers and which has a coach.
- Points to one of the (currently) 8 types of equipment that can be accepted and used for Tournament equipment registration.
- Equipment is part of an EquipmentSet. If there is not set for it to be a part of then it is assigned to a default "independent" EquipmentSet which each User has 1 of (not needed until there is at least one piece of Equipment that is not assigned to an EquipmentSet).
- A record created when an EqupimentOwner registers either a single piece of equipment or an EquipmentSet for a Tournament.
- A column in this table holds a nullable reference for the 1-to-1 relationship of the EquipmentRegistration record to a Room it has been deployed to during the Tournament.
- A a set of different kinds of equipment (listed below) that form a set (or which are organized into a set).
- Each EquipmentSet is managed by an EquipmentOwner (one of several roles that a User can adopt, this role being able to be adopted via creating an EquipmentSet).
- This should be modifiable both on its own and when registering equipment for a Tournament (the latter allowing the EquipmentOwner to update the EquipmentSet BEFORE registering the whole set for use in a Tournament).
- During equipment registration for a Tournament, the design intent is for the EquipmentSet to be selectable by the EquipmentOwner and thereby register all equipment associated with the EquipmentSet to be used in that Tournament (where each piece of equipment then creates an EquipmentRegistration record in that respective table).
- For equipment not part of a set, we could implement this by creating a default "independent equipment" EquipmentSet. This way each piece of a equipment always has a reference to a certain EquipmentSet (and the FK column therefore can be implemented as NOT NULL).
- The laptop or other computer device (RaspberryPi) that runs QuizMachine client for a specific Room during the Tournament.
- A string of 5 jump pads connected via a single wire which plugs into the InterfaceBox for communicating jump status for each jump pad to QuizMachine.
- Also called a "QBox" (plus some other variants), this allows communication from the JumpPads to the Computer which runs QuizMachine client.
- Connects to the Computer to display the UI of the Computer to the Quizzers (usually placed on the floor). "Mirror mode" is usually used on the Computer to ensure everyone sees the same single screen which the QuizMaster can also see and interact with.
- An external audio recorder. Used en lieu of the QuizMachine client's recording software not working correctly. Today a smartphone audio recorder would suffice so we don't see too many of these being registered today.
- An alternative to a Monitor. Used for the same purposes.
- Your average Powerstrip with surge protection (usually). Used for powering the InterfaceBox, Computer and Monitor(s). Placed at the QuizMaster's feet.
- Used for extending electrical power reach across a room to the quiz equipment.