CASE-05
System Implementation

CLMS — Teaching Business Management System

Learning Business Management System

CLMS — Teaching Business Management System
Business DiscoveryProduct ThinkingDomain ModelingSaaS ArchitectureAI-assisted Engineering

Overview

CLMS (Course & Lesson Management System) is a fully self-developed international teaching management system. As students and courses grew, the old way started to break: missed or wrong class times, miscalculated amounts, time-consuming monthly reports, scattered student status, complex leave and make-up, hard-to-maintain pricing, and international timezones with DST adding scheduling complexity.

No off-the-shelf product fit, so we built our own — turning the fragmented teaching and operations rules into one unified domain model.

The Challenge

The system had to keep answering: who teaches today? how many lessons done? how much is due? who starts when? who is on leave? who needs a make-up? who needs follow-up? what is this month’s report?

Off-the-shelf tools — spreadsheets, generic SaaS, school systems — could not unify these rules in one verifiable model.

Solution

Around domain modeling, I built the backbone Course → Class → Student → Enrollment → Lesson (Lesson is the standardized object linking teaching records, scheduling, leave, make-up, and billing).

Billing supports monthly (fixed fee, unaffected by a single leave) and per-lesson (by actual teaching time); pricing supports per-student rates, historical price retention, and natural-month activation without backdating; leave and make-up are distinguished on teacher vs student sides; multi-currency — mainly IDR, also USD, AUD, CNY, MYR, THB and more — with per-student currency, date-based rates, and historical rate retention.

Domain Backbone

Course
Class
Student
Enrollment
Lesson

Architecture Layers

Domain
Service
Repository
HTTP / UI
CLMS — Teaching Business Management System 流程图 1

Implementation

I owned requirement analysis, business-rule modeling, domain modeling, product design, architecture decisions, AI-assisted implementation, and testing.

AI was leverage for engineering, not the product decision-maker — more precisely, AI-assisted Engineering: understand the problem, design the solution, use AI to implement, apply human judgment, iterate.

Key Capabilities

  • Business Discovery

    Finding productizable rules inside a real business.

  • Domain Modeling

    Turning fuzzy business rules into a testable domain model.

  • Product Thinking

    Balancing business goals, complexity, and cost.

  • SaaS Architecture

    Designing system layers around an evolvable model.

  • AI-assisted Engineering

    Using AI to raise engineering efficiency, with humans owning key decisions.

  • Financial Precision

    Precise modeling and testing of billing, FX, and historical prices.

Deliverables

A SaaS product exploration driven by a real business, carrying business rules all the way into product and engineering: the domain model and core rules are live in actual use, with courses, billing, leave, make-up, and reporting forming a working loop.

Takeaway

This project reinforced my belief: the value of complex business work often lies not in lines of code but in turning real rules into a verifiable model.

Tech Stack

Domain Layer

Business RulesDomain Model

Service Layer

Application Services

Repository Layer

Data Access

HTTP / UI Layer

APIFrontend

Engineering Note

Business rules are decoupled from the UI / HTTP layer, leaving room for future SQLite → PostgreSQL migration and single-user → multi-role expansion.

Next Step

Good products often start from a real business’s “can’t calculate, can’t remember, can’t reconcile” — turning fuzzy rules into a testable domain model.

Contact