Backend Development for an MBTI Personality Test Application (Basics)

  • Requirement Analysis
  • Database Schema Design
  • Backend Project Initialization
  • Basic Backend Development – CRUD Operations
  • Interface Development
  • Service Layer Implementation
  • Core Business Logic

Requirement Analysis

The goal here is to clearly define what needs to be built and prioritize these requirements to shape the development roadmap.

a. Functional Breakdown

Modules and their associated functionalities:

  • User Module
    • Registration
    • Login
    • User Management (CRUD) – Admin-only
  • Application Module
    • Create application
    • Edit application
    • Delete application
    • List applications
    • View application details
    • View applications created by the user
    • Manage applications (CRUD) – Admin-only
    • Review and publish/unpublish applications – Admin-only
    • Share application via QR code
  • Question Module
    • Create questions with scoring options
    • Edit questions
    • Delete questions
    • Manage questions (CRUD) – Admin-only
    • AI-generated questions
  • Scoring Module
    • Create scoring results
    • Edit scoring results
    • Delete scoring results
    • Claculate scores based on answers (various strategies)
      • Custom rule scoring – Assessment type
      • Custom rule scoring – Rating type
      • AI-based scoring
    • Manage scoring results (CRUD) – Admin-only
  • Answer Module
    • Submit answers
    • View scoring result for a submission
    • View list of submitted answers
    • Manage answers (CRUD) – Admin-only
  • Analytics Module
    • Analyze and view application scoring results

b. Core Workflow

Workflow diagram:

Textual representation:

  1. User registers → User logs in
  2. User creates an application → Creates questions (with scoring) → Defines scoring rules
  3. Admin reviews and approves/rejects the application
  4. Users browse and find applications, enter details, take tests, and submit responses
  5. After scoring calculation, users see their results

c. Requirement Prioritization

Based on workflow, prioritize features:

  • P0: Must-have
  • P1: Important features
  • P2: Useful features
  • P3: Nice-to-have features

Priority list:

  • User Module
    • Registration P0
    • Login P0
    • User Management (CRUD) P1
  • Application Module
    • Create application P0
    • Edit application P1
    • Delete application P1
    • List applications P0
    • View application details P0
    • View own applications P1
    • Manage applications (CRUD) P0
    • Review and publish/unpublish P0
    • Share via QR code P2
  • Question Module
    • Create question with options P0
    • Edit question P1
    • Delete question P1
    • Manage questions (CRUD) P1
    • AI-generated questions P1
  • Scoring Module
    • Create scoring results P0
    • Edit scoring results P1
    • Delete scoring results P1
    • Scoring logic (multiple strategies)
      • Custom rule scoring – Assessment type P0
      • Custom rule scoring – Rating type P0
      • AI-based scoring P1
    • Manage scoring results (CRUD) P1
  • Answer Module
    • Submit answer P0
    • View scoring result P0
    • View submitted answers P1
    • Manage answers (CRUD) P1
  • Analytics Module
    • View scoring analytics P2

Database Schema Design

Based on the functional modules defined above, we will design six core tables (excluding analytics for now).

Database name: yudada

Initialization scripts:

  • Create tables: create_table.sql
  • Initial data: init_data.sql

All tables should include fields like creation time, update time, and deletion flag.

a. User Table

b. Application Table

Review status fields:

reviewStatus    int      default  0  not null comment 'Review status: 0-Pending, 1-Approved, 2-Rejected',
reviewMessage   varchar(512)   null comment 'Review message',
reviewerId      bigint         null comment 'Reviewer ID',
reviewTime      datetime       null comment 'Review timestamp',

c. Question Table

Each application has one record in this table. The questionContent JSON field stores all questions and options for that application.

Structure:

[
  {
    "options": [
      {
        "result": "I", // For assessment-type apps
        "score": 1,    // For rating-type apps
        "value": "Option A",
        "key": "A"
      },
      {
        "result": "E",
        "score": 0,
        "value": "Option B",
        "key": "B"
      }
    ],
    "title": "Question Title"
  }
]

d. Scoring Result Table

This table holds the results assigned to users after answering questions. Different application types use different fields:

  • Assessment-type apps use resultProp
  • Rating-type apps use resultScoreRange

Tags: Backend database mbti API CRUD

Posted on Thu, 01 Oct 2026 16:51:52 +0000 by biffjo