docs: Added initial documentation of hld, lld and erd.#69
docs: Added initial documentation of hld, lld and erd.#69mahmoodcli wants to merge 1 commit intomainfrom
Conversation
| ### 4.1 End user types | ||
|
|
||
| 1. **Unauthenticated user (if supported)** | ||
| - Accesses public pages and journeys that do not require sign-in. |
There was a problem hiding this comment.
We aren't supporting unauthenticated users
| - Accesses public pages and journeys that do not require sign-in. | ||
|
|
||
| 2. **Authenticated user (DfE Sign-in)** | ||
| - Typical users: school staff and local authority staff. |
There was a problem hiding this comment.
Also Multi-Academy Trust executives
| PostgreSQL is the system of record for persisted data used by the service. Typical categories include: | ||
| - School identity and attributes (e.g., URN, name, address, LA) | ||
| - Attributes required for filtering and comparison (phase/type/status) | ||
| - Metrics or performance-related values (if stored) |
There was a problem hiding this comment.
We will be storing these
| 1. User selects a school and chooses “compare” | ||
| 2. Web calls the Compare use-case | ||
| 3. Application service determines a set of similar schools: | ||
| - may be derived via rules and/or Lucene and/or stored relationships (depending on implementation) |
There was a problem hiding this comment.
This will be a set of pre-calculated stored relationships
|
|
||
| 1. User requests a protected feature/page | ||
| 2. Web layer redirects to DfE Sign-in for authentication | ||
| 3. User returns with identity/claims |
There was a problem hiding this comment.
DfE Sign-in returns with identity/claims
|
|
||
| ### Error handling | ||
|
|
||
| - Expected outcomes returned as result objects |
There was a problem hiding this comment.
We don't use result objects currently but we probably should do
| - **SchoolMetric** (numeric/time-series values used for compare) | ||
| - **SimilarSchool** (optional: stored similarity relationships) | ||
|
|
||
| If your implementation does not store some of these (e.g., similarity is computed dynamically), remove those entities from this ERD. |
There was a problem hiding this comment.
We need to think some more about these
| - no persistent relationship table exists | ||
|
|
||
| This approach avoids circular dependencies in the ERD and reflects the implementation accurately. | ||
|
|
There was a problem hiding this comment.
We need to rethink this section - there aren't currently any foreign keys in the database, not sure there will be, so there aren't any relational joins. And the database views/tables don't match what's described here
| - Fetch from `SCHOOL` and any related tables needed for display: | ||
| - characteristics | ||
| - metrics | ||
| - local authority |
There was a problem hiding this comment.
We need to revisit this, there is no SCHOOL table and the related tables don't match the database
| ### 6.3 Compare similar schools | ||
| - Identify a comparison set: | ||
| - from a similarity join table (if stored), or | ||
| - derived dynamically via rules/search |
There was a problem hiding this comment.
This will be stored, and not derived dynamically
3 participants
No description provided.