Skip to content
Santekno.com | Level Up Your Engineering Skills
ID
📖 0%
22 Jul 2025 · 5 mnt baca ·Artikel 22 / 125
Go

22 Membuat Sub-Schema Berdasarkan Modul

IH
Ihsan Arif
Penulis di Santekno · Backend Engineer

22 Membuat Sub-Schema Berdasarkan Modul: Panduan Praktis untuk Arsitektur Data yang Modular

Di dunia pengembangan aplikasi modern, terutama ketika kita berbicara tentang sistem berskala besar atau microservices, pengelolaan skema data sering kali menjadi tantangan tersendiri. Salah satu pendekatan yang banyak digunakan adalah modularisasi skema — di mana masing-masing modul fitur aplikasi memiliki sub-schema (subs-kema) tersendiri. Dalam artikel ini, kita akan membahas secara mendalam tentang membuat sub-schema berdasarkan modul di project backend, lengkap dengan contoh kode, simulasi kasus, serta diagram alur pembentukan skema yang terintegrasi.


Mengapa Perlu Sub-Schema per Modul?

Mari kita mulai dengan pertanyaan mendasar: Kenapa perlu membuat sub-schema berdasarkan modul?

Beberapa alasannya antara lain:

  • Organisir kode lebih rapi: Skema data milik fitur spesifik hanya tinggal di folder modul miliknya.
  • Kemudahan scaling dan maintainability: Saat menambah/merubah fitur, hanya perlu menyentuh bagian yang related.
  • Mencegah “Entitas God”: Satu file schema besar membuat data model sulit dipelihara dan rentan terjadi konflik saat kolaborasi antar engineer.

Studi Kasus: Proyek CRUD Sederhana

Kita asumsikan membangun aplikasi RESTful sederhana dengan dua modul utama: Users dan Posts. Masing-masing punya schema dan logika sendiri. Kita akan pakai MongoDB dan Mongoose pada Node.js untuk ilustrasi implementasi.

Struktur folder project modular:

text
 1src/
 2 3├── modules/
 4│   ├── user/
 5│   │   ├── user.model.js
 6│   │   └── user.controller.js
 7│   └── post/
 8│       ├── post.model.js
 9│       └── post.controller.js
1011├── app.js
12└── database.js

Membuat Sub-Schema: Contoh Implementasi

1. User Schema

js
 1// src/modules/user/user.model.js
 2const mongoose = require('mongoose');
 3
 4const userSchema = new mongoose.Schema({
 5    name: { type: String, required: true },
 6    email: { type: String, unique: true },
 7    password: { type: String, required: true },
 8    createdAt: { type: Date, default: Date.now }
 9});
10
11module.exports = mongoose.model('User', userSchema);

2. Post Schema dengan Sub-Schema (Embedded)

Akan lebih menarik jika di modul Post, kita embed sub-schema Comment khusus:

js
 1// src/modules/post/post.model.js
 2const mongoose = require('mongoose');
 3
 4const commentSchema = new mongoose.Schema({
 5    user: { type: mongoose.Schema.Types.ObjectId, ref: 'User' },
 6    message: { type: String, required: true },
 7    postedAt: { type: Date, default: Date.now }
 8}, { _id: false }); // Sub-schema: komentar tidak perlu _id terpisah
 9
10const postSchema = new mongoose.Schema({
11    title: String,
12    content: String,
13    author: { type: mongoose.Schema.Types.ObjectId, ref: 'User' },
14    comments: [commentSchema] // Array sub-schema
15});
16
17module.exports = mongoose.model('Post', postSchema);

Keuntungan:
Sub-schema Comment BERBEDA dengan schema utama User & Post, sehingga bisa evolve mandiri sesuai kebutuhan Post.


Simulasi Relasi dan Modularisasi

Lihat berikut, setiap module punya tanggung jawab terhadap sub-schema-nya masing-masing. Untuk ilustrasi relasi dan modularity, berikut diagram alur pengelolaan data saat menambah post baru beserta komentar:

MERMAID
flowchart TD
    A[Client Request: Buat Post] --> B[Modul Post Menerima Request]
    B --> C[Akses User (author) dari Modul User]
    C --> D[Lolos? Continue, Gagal? Reject]
    D --> E[Modul Post Membuat Data Post (dengan Comments sbg Sub-Schema)]
    E --> F[Simpan ke Database]
    F --> G[Response ke Client]

Flow di atas jelas modular: module Post mengelola Post+Comment, dan module User hanya jadi referensi. Sub-schema Comment exclusive milik Post.


Studi Tabel: Modularisasi Vs. Schema Global

PendekatanKelebihanKekurangan
Schema GlobalPenyederhanaan schema (model satu tempat)Sulit maintain, rentan kesalahan
Sub-Schema ModularMudah dikembangkan per module, scalablePerlu strategi integrasi & dependency

Tips & Best Practice Sub-Schema Modular

  1. Pisahkan Folder Schema per Modul
    Agar source code mudah dirawat dan scalable.

  2. Jangan Duplicate Skema Antar Modul
    Jika ada schema kecil yang dipakai di banyak module (misal Address), taruh di shared schemas.

  3. Gunakan Referensi jika Entitas Besar
    Untuk data besar atau berubah cepat (misal User), disarankan oleh MongoDB untuk pakai ref daripada embedded sub-schema.

  4. Testing Unit untuk Setiap Schema
    Modularisasi akan mempermudah pembuatan unit-test model yang isolated.


Integrasi Semua Sub-Schema: Entry Point Aplikasi

Saat app dijalankan, biasanya main app akan mendaftarkan semua schema di entry-point, tapi kode schema dan logika tetap diserahkan ke masing-masing modul, misal:

js
 1// app.js
 2const express = require('express');
 3const mongoose = require('mongoose');
 4
 5// Connect to MongoDB (sesuai file database.js)
 6mongoose.connect('mongodb://localhost:27017/myapp');
 7
 8const app = express();
 9app.use(express.json());
10
11// Import router dari masing-masing modul
12const userRoutes = require('./modules/user/user.controller');
13const postRoutes = require('./modules/post/post.controller');
14
15app.use('/users', userRoutes);
16app.use('/posts', postRoutes);
17
18app.listen(3000, () => console.log('Server running at http://localhost:3000'));

Simulasi API Request

Buat Post baru:

json
1POST /posts
2{
3  "title": "Membuat Sub-Schema Modular",
4  "content": "Sub-schema itu solusi arsitektural yang powerful.",
5  "author": "665e752f92a014c5efa4fbc9",
6  "comments": [
7    {"user": "665e752f92a014c5efa4fbc9", "message": "Nice post, thanks!"}
8  ]
9}

Respons dari server akan mengandung komentar sebagai sub-document di dalam comments.


Penutup: Kapan Harus Modularisasi Schema?

Modul schema sangat bermanfaat untuk:

  • Aplikasi growing fast, banyak fitur baru
  • Tim developer ukuran >3
  • Backend siap microservices/monolith serviceful

Dengan sub-schema per modul, arsitektur project backend jadi robust dan scalable.

Danger
Catatan engineer senior:
“Modularizing schemas is an investment in maintainability. It might seem verbose at first, but it pays off quickly as your team and app grows.”

Semoga penjelasan dan simulasi pada artikel “Membuat Sub-Schema Berdasarkan Modul” ini membantu memberikan wawasan arsitektur backend yang solid dan siap scale! Jangan ragu untuk coba modularisasi schema di project Anda berikutnya. 🚀


Referensi

Artikel Terkait

💬 Komentar