VTRC Knowledge Manual (V2)

ธีม

6.1 · Repository map + dead code ​

บทนี้สำรวจโครงสร้างของ benefit-api/ ตั้งแต่ root ถึงโฟลเดอร์ src/, libs/, config/ พร้อมระบุขนาดไฟล์และ dead code ที่ตรวจพบ

Branch และ commit ​

ข้อมูลค่า
Branch ที่ใช้งานจริงprod
HEAD commit ณ เวลาที่เขียนe3be391 [hotfix] add ' exportPayDate
Default branchmaster (sparse — code จริงอยู่บน prod)
จำนวน tracked files172
ลักษณะ commit historyมี hotfix เยอะมาก (IN402, IN401, IN384, …) — production under active patching

ไฟล์ root ​

ไฟล์บทบาทขนาด/หมายเหตุ
package.json:1-111NestJS 9 project (name: vtrc-restfull-v2)111 บรรทัด
tsconfig.json:1-22TypeScript configtarget: es2017, strictNullChecks: false, noImplicitAny: false — typing lenient มาก
Dockerfile:1-30base node:20-alpine + chromium สำหรับ PuppeteerEXPOSE 9320
.env:1-64committed secrets — ดู 6.8 S11,615 bytes
.dockerignore:1มีแค่ yarn.locktrivial
.gitignore:1-55ระบุ .env ในบรรทัด 55 — แต่ .env tracked อยู่แล้วcontradictory
bitbucket-pipelines.yml:1-138CI/CD — build ทุก branch สำคัญ (cicd, feature/*, hotfix/*, develop, uat, prod, master); push ไป GCRlint/test ถูก comment ไว้
docker-compose.yml:1-31dev container + MSSQL 2019 (SA_PASSWORD=abcABC123)password leaked
nest-cli.json, tsconfig.build.jsonstandard NestJS
README.md:1-74default NestJS starter README — ไม่ได้เขียนเฉพาะโปรเจกต์unused

ไม่พบ .env.example — .env คือไฟล์จริงที่ใช้งานและ commit เข้า repo ไปแล้ว

โครงสร้าง src/ ​

src/
├── main.ts                          (47 บรรทัด)  ← bootstrap
├── app.module.ts                    (79 บรรทัด)  ← 3 TypeORM connections
├── app.controller.ts                (66 บรรทัด)  ← SSRF + debug (ดู 6.8 S3, S5)
├── app.service.ts                   (4 บรรทัด)   ← empty stub — DEAD
├── dto/                             (18 DTO files, ~3,884 บรรทัดรวม)
│   ├── disaster.dto.ts              (862 บรรทัด)
│   ├── payment.dto.ts               (866 บรรทัด)
│   ├── approveDisaster.dto.ts       (366 บรรทัด)
│   ├── wdhospitals.dto.ts           (415 บรรทัด)
│   ├── disbursement.dto.ts          (290 บรรทัด)
│   └── ... (13 files เพิ่ม)
├── entities/                        (26 entity files — ดู 6.6)
│   ├── paymentTransaction.entity.ts (210 บรรทัด, ~90 fields)  ← central entity
│   ├── wdHospitals.entity.ts        (221 บรรทัด)
│   └── ...
├── modules/                         (12 feature modules)
│   ├── approveDisaster/    approvedisaster.{controller,service,module}.ts
│   ├── batchJob/           manualBatch.*  (Public endpoints, no auth)
│   ├── chartOfAccount/
│   ├── disaster/
│   ├── disbursement/
│   ├── dropdown/           (5 routes — ทั้งหมด @Public)
│   ├── export-payments/    export-payments.* (1,201-line service)
│   ├── exportPaymentReport/ exportpaymentreport.* (**7,740-line single service**)
│   ├── payments/           payments.* (1,450-line service)
│   ├── setupPayor/
│   ├── studyLeave/         (single POST, no validation — `body: any`)
│   ├── uploadFiles/        upload.* (Public)
│   └── wdhospitals/        wdhospitals.* (3 Public mutation endpoints)
└── crontab/
    ├── cronTab.module.ts / cronTab.service.ts    (2 cron jobs)
    ├── funeral/      funeral.task.service.ts     (576 บรรทัด)
    └── inheritance/  inheritance.task.service.ts (657 บรรทัด)

ขนาด service files (เรียงจากใหญ่ที่สุด) ​

7,740  src/modules/exportPaymentReport/exportpaymentreport.service.ts   ← god object
1,450  src/modules/payments/payments.service.ts
1,201  src/modules/export-payments/export-payments.service.ts
  954  src/modules/disbursement/disbursement.service.ts
  825  src/modules/disaster/disaster.service.ts
  657  src/crontab/inheritance/inheritance.task.service.ts
  576  src/crontab/funeral/funeral.task.service.ts
  453  src/modules/approveDisaster/approvedisaster.service.ts
  257  src/modules/wdhospitals/wdhospitals.service.ts
  171  src/modules/chartOfAccount/chartofaccount.service.ts
  154  src/modules/dropdown/dropdown.service.ts
  133  src/modules/setupPayor/setuppayor.service.ts

ไฟล์ exportpaymentreport.service.ts ที่ 7,740 บรรทัดใน class เดียว เป็น anti-pattern ขั้นสุด — เป็นสาเหตุหลักที่ทำให้การแก้ไข report ใด ๆ มีความเสี่ยงสูง เพราะแตะส่วนหนึ่งอาจกระทบส่วนอื่นที่ไม่เกี่ยวข้อง

โครงสร้าง libs/ (shared, 16 files) ​

โฟลเดอร์ไฟล์บทบาท
libs/jwt/jwt.strategy.ts, jwt-auth.guard.tsauth — ดู 6.5
libs/log/logs.middleware.tsI3GatewayLogger
libs/exception/http-exception.filter.tsglobal exception filter
libs/common/base64-to-file.ts, file-path-to-base64.ts, ganarate-random-string.ts (sic), paginate.ts, remove-file.ts, validator-date.tsutility
libs/utils/welfare.util.ts, running.util.ts, lists.util.ts, dropdown.util.ts, check-emp-wd.util.tsdomain utility
libs/pdfTemplate/17 EJS templatesPDF generation — disaster-report, fmis/bgdoc, fmis/general, payment/ac011, ฯลฯ

โฟลเดอร์ sql/ ​

มี MSSQL schema dumps ของ initial DB structure — เช่น sql/benefit_20230222_mssql_initial_structure.sql เป็น snapshot วันที่ 2023-02-22 ไม่ได้ใช้สำหรับ migration อัตโนมัติ แต่ใช้เป็น reference เท่านั้น

Dead code / unused code ​

รายการ dead code ที่ตรวจพบ:

ไฟล์:บรรทัดรายละเอียด
src/app.service.ts4 บรรทัด, class เปล่า — เป็น default NestJS starter stub ที่ไม่ได้ใช้
src/modules/payments/payments.controller.ts:91-95commented-out createExportWDHospital
src/modules/uploadFiles/upload.controller.ts:25-35commented-out update / deleteSurvey
src/modules/exportPaymentReport/exportpaymentreport.service.ts:5459-5812block ใหญ่ของ SFTP code ที่ถูก comment ออก (ถูกแทนด้วย ledger logic ใหม่ที่บรรทัด :5818)
src/modules/exportPaymentReport/exportpaymentreport.service.ts:58import { SftpUpload } from 'sftp-upload' import เข้ามาแต่ไม่เคย instantiate (ใช้แค่ ssh2-sftp-client)
src/app.controller.ts:19-59testProfile — debug leftover ที่ยังอยู่ใน prod branch (hardcoded apiKey + UAT endpoint)
src/modules/export-payments/export-payments.controller.ts:44-62GET test/:id — debug route ใน production
src/modules/exportPaymentReport/exportPaymentReport.controller.ts:62-70exportReportByOrderExcel ติด @Public() (ไม่น่าจะตั้งใจ)

README.md:1-74 ก็เป็น default NestJS starter README — ไม่ได้เขียนถึง benefit-api เลย

สรุป ​

benefit-api เป็น service ขนาดกลาง (~108 TypeScript files ใน src/libs/config) ที่มีจุดเด่นคือความซับซ้อนของ business logic (welfare, disbursement, FMIS integration) แต่ขาดการแบ่ง bounded context ชัดเจน — เกือบทุกอย่างอยู่ใน modules/ โดยไม่มี domain folder separation, และมี god object หนึ่งตัว (exportpaymentreport.service.ts) ที่ทำหน้าที่รวม report generation ทุกชนิด

ไปต่อ ​