Evolusi Struktur Folder dalam Software Engineering

Dalam dunia Software Engineering, perubahan tidak hanya terjadi pada bahasa pemrograman atau framework. Salah satu hal yang ikut berkembang adalah struktur folder dalam aplikasi.

Banyak developer pemula menganggap struktur folder hanyalah soal kerapihan. Padahal, struktur folder mencerminkan cara berpikir engineering pada zamannya.

Semakin matang pengetahuan software engineering, semakin berkembang pula cara kita menyusun kode.

---

Timeline Evolusi Struktur Folder (1990–2026)

Sebelum masuk ke detail tiap pendekatan, penting untuk melihat gambaran besarnya — bagaimana perubahan ini terjadi secara historis.

Periode	Pendekatan	Pemicu Perubahan
1990–1999	Tanpa konvensi (flat files)	Web baru lahir, fokus hanya "bisa jalan"
2000–2004	MVC masuk ke web	Struts (2000), Spring Framework (2003), buku Martin Fowler (2002)
2005–2009	MVC menjadi standar	Ruby on Rails (2005), Django (2005) — "convention over configuration"
2010–2014	Layered + DDD mulai mainstream	Node.js/Express, Domain-Driven Design diadopsi luas, microservices mulai diperbincangkan
2012–2016	Clean Architecture & Microservices	Uncle Bob perkenalkan Clean Architecture (2012), Docker (2013), Netflix & Amazon pelopori microservices
2016–2019	Feature-Based & Container era	Kubernetes meluas (2016–2018), NestJS (2017), serverless functions berkembang
2020–2022	Modular Monolith bangkit kembali	Microservices dianggap terlalu kompleks untuk banyak tim, monorepo (Nx, Turborepo) naik daun
2023–2026	Keberagaman & konteks	Tidak ada satu arsitektur terbaik — pilihan bergantung pada skala, tim, dan kecepatan iterasi

Setiap perubahan bukan muncul karena tren semata. Tiap era lahir karena masalah nyata yang tidak bisa diselesaikan oleh pendekatan sebelumnya.

---

Awal Mula: Ketika Aplikasi Masih Sederhana

Pada masa awal pengembangan aplikasi, kebutuhan sistem masih relatif kecil:

jumlah fitur sedikit

tim kecil atau solo developer

deployment sederhana

perubahan tidak terlalu sering

Karena itu, struktur folder biasanya sangat sederhana.

/controllers
/models
/views

Model seperti ini populer pada pola MVC (Model-View-Controller).

Setiap file dikelompokkan berdasarkan jenisnya. Semua controller di satu tempat, semua model di satu tempat.

Kelebihan

mudah dipahami pemula

cepat dibuat

cocok untuk aplikasi kecil

Kekurangan

Saat aplikasi membesar:

controller menjadi sangat banyak

model sulit dicari

satu fitur tersebar ke banyak folder

maintenance makin sulit

Kapan Simple MVC Tepat Digunakan

Struktur ini cocok untuk:

Company profile / landing page — website statis dengan sedikit form dan halaman

Internal tool sederhana — dashboard absensi karyawan, form pengajuan izin

Prototype / MVP awal — validasi ide dalam 1–2 minggu, belum perlu skalabilitas

Side project solo developer — blog pribadi, portfolio, tools CLI kecil

Contoh nyata: sebuah startup baru yang membangun halaman pendaftaran waitlist dengan fitur email notifikasi. Struktur MVC sudah lebih dari cukup.

---

Fase Pertumbuhan: Layered Architecture

Ketika aplikasi mulai kompleks, muncullah pendekatan berbasis layer:

/controllers
/services
/repositories
/models

Di sini logika bisnis mulai dipisahkan ke folder /services, akses database ke /repositories.

Ini langkah maju penting karena developer mulai memahami konsep:

separation of concerns

single responsibility

reusable business logic

Dampak Positif

Kode menjadi lebih terstruktur dan tanggung jawab tiap layer lebih jelas.

Namun saat sistem sangat besar, masalah baru muncul.

Jika ingin melihat fitur "Order", developer harus membuka:

controller order

service order

repository order

model order

Semua tersebar.

Kapan Layered Architecture Tepat Digunakan

Layered architecture cocok saat:

REST API dengan 5–15 endpoint — backend untuk aplikasi mobile atau web yang mulai berkembang

Sistem booking sederhana — reservasi restoran, booking lapangan futsal, jadwal dokter

E-commerce awal — toko online dengan fitur produk, keranjang, dan order dasar

Tim 2–5 developer — butuh konvensi bersama tapi belum perlu pembagian modul yang kompleks

Contoh nyata: tim 3 developer membangun API untuk aplikasi kasir toko retail. Ada fitur produk, transaksi, dan laporan. Layered architecture membuat pembagian tugas lebih mudah tanpa overhead yang besar.

---

Era Modern: Feature-Based Structure

Saat tim dan produk makin besar, fokus berpindah dari "jenis file" menjadi fitur bisnis.

Muncullah struktur seperti:

/modules
  /users
  /orders
  /payments

Di dalam tiap module:

/orders
  order.controller.ts
  order.service.ts
  order.repository.ts
  order.model.ts
  order.dto.ts
  order.spec.ts

Kenapa Ini Lebih Disukai

Karena developer bekerja berdasarkan fitur, bukan berdasarkan jenis file.

Saat diminta mengerjakan Order Module, semua kebutuhan ada di satu tempat — termasuk test-nya.

Cocok Untuk

startup yang berkembang cepat

tim menengah hingga besar (5–20 developer)

aplikasi dengan banyak fitur yang terus bertambah

Kapan Feature-Based Tepat Digunakan

SaaS product — platform HR, project management tools, atau CRM dengan puluhan fitur

Multi-tenant application — satu backend melayani banyak klien dengan konfigurasi berbeda

Aplikasi startup Series A ke atas — produk yang sudah terbukti dan sedang scaling

Backend NestJS atau Spring Boot — framework ini memang dirancang untuk pendekatan modular

Contoh nyata: startup fintech yang membangun aplikasi pinjaman dengan modul users, loans, repayments, notifications, dan reports. Setiap squad bisa mengerjakan modul masing-masing tanpa konflik merge yang besar.

---

Tahap Kematangan: Clean Architecture

Ketika software engineering semakin matang, muncul kebutuhan yang lebih dalam:

kode mudah di-test

tidak tergantung framework

domain bisnis terlindungi

scalable untuk jangka panjang

Muncullah Clean Architecture:

/src
  /Domain
    /Entities
    /ValueObjects
    /Repositories (interfaces)
  /Application
    /UseCases
    /DTOs
  /Infrastructure
    /Database
    /ExternalAPIs
  /Presentation
    /Controllers
    /Middlewares

Filosofinya

Dependency harus mengarah ke pusat (business rules), bukan ke luar.

Artinya:

database bisa diganti (PostgreSQL → MongoDB) tanpa ubah domain

framework bisa diganti (Express → Fastify) tanpa ubah use case

UI bisa berubah tanpa menyentuh logic

domain logic tetap aman dan mudah di-test secara unit

Kapan Clean Architecture Tepat Digunakan

Clean Architecture bukan untuk semua project. Ini tepat jika:

Sistem fintech atau perbankan — domain rules kompleks, regulasi ketat, audit trail wajib ada

Healthcare system — data pasien, rekam medis, integrasi dengan perangkat medis

Enterprise ERP — logika bisnis yang sering berubah mengikuti kebijakan perusahaan

Platform yang butuh long-term maintainability — sistem yang akan dikembangkan selama 5–10 tahun ke depan

Contoh nyata: platform asuransi digital yang harus mengikuti regulasi OJK. Domain rules untuk perhitungan premi dan klaim sangat kompleks. Clean Architecture memungkinkan tim mengganti provider payment dan mengupdate aturan bisnis tanpa risiko memecah bagian lain.

---

Lalu Hadir Microservices

Ketika satu aplikasi terlalu besar, organisasi mulai memecah sistem menjadi beberapa service independen:

/user-service
/payment-service
/product-service
/notification-service
/api-gateway

Masing-masing service punya struktur internal sendiri, database sendiri, dan deployment sendiri.

Ini bukan sekadar struktur folder lagi, tetapi evolusi menuju struktur sistem.

Kapan Microservices Tepat Digunakan

Microservices bukan solusi default — ini solusi untuk masalah skala tertentu:

Platform marketplace besar — seperti Tokopedia atau Bukalapak, di mana fitur checkout, search, dan chat harus bisa scale secara independen

Super-app — aplikasi seperti Gojek yang menggabungkan ride-hailing, food delivery, payment, dan logistik

Tim besar dengan squad independen — 50+ developer, masing-masing squad punya ownership penuh atas service-nya

Sistem dengan traffic tidak merata — notification service butuh 10x lebih banyak resource saat event flash sale, tapi billing service tidak

Contoh nyata: platform e-learning dengan jutaan pengguna. Service video-streaming butuh infrastruktur CDN khusus, sementara service quiz hanya butuh server kecil. Dengan microservices, keduanya bisa di-scale secara independen sesuai kebutuhan.

---

Antara Monolith dan Microservices: Modular Monolith

Ketika Clean Architecture sudah diterapkan tapi tim belum siap dengan kompleksitas microservices, ada satu pilihan yang sering dilewati begitu saja: Modular Monolith.

Modular Monolith masih satu deployment unit seperti monolith biasa — tapi batas antar modul ditegakkan secara eksplisit oleh tooling, bukan hanya konvensi folder.

/modules
  /orders
    /public           ← hanya ini yang boleh diakses modul lain
      index.ts
    /internal         ← tersembunyi dari dunia luar
      service.ts
      repository.ts
  /notifications
    /public
      index.ts
    /internal
      service.ts

Yang membedakannya dari Feature-Based:

Di Feature-Based, modul orders bisa langsung mengimpor class apapun dari modul notifications

Di Modular Monolith, modul orders hanya bisa mengakses apa yang diekspos lewat public API modul notifications

Batas ini ditegakkan oleh tooling — ESLint rules (Node.js), internal keyword (C#), atau import-linter (Python) — bukan sekadar kesepakatan tim

Mengapa Ini Penting

Modular Monolith menjadi jembatan yang sangat berguna:

Satu deployment — tidak ada kompleksitas distributed system seperti network failure, retry, atau eventual consistency

Batas yang sudah jelas — jika suatu hari ingin migrasi ke microservices, batas modul sudah terdefinisi dengan baik dan teruji

Developer experience lebih baik — tidak ada contract testing, tidak ada network call antar modul, tapi kode tetap terorganisir secara ketat

Kapan Modular Monolith Tepat Digunakan

Tim yang sudah outgrow Feature-Based tapi belum siap dengan kompleksitas microservices

Sistem yang kemungkinan akan dipecah ke microservices di masa depan — Modular Monolith adalah persiapan terbaik

Organisasi dengan 10–30 developer yang masih ingin single deployment

Sistem dengan kebutuhan konsistensi data tinggi yang tidak cocok untuk distributed transaction

Contoh nyata: startup fintech Series B yang memiliki 15 developer. Sistem sudah terlalu besar untuk Feature-Based tapi belum memerlukan infrastruktur microservices. Modular Monolith memungkinkan mereka mempertahankan kecepatan iterasi sambil menjaga batas antar domain bisnis tetap bersih.

---

Apakah Semua Arsitektur Bisa Di-Test

Ya — semua bisa. Tapi kualitas dan kemudahannya sangat berbeda.

Arsitektur	Unit Test	Integration Test	Kemudahan Mock
Simple MVC	Sulit — logic dan I/O bercampur di controller	Bisa, tapi butuh DB nyata	Harus mock banyak hal sekaligus
Layered	Sedang — service bisa di-test, tapi sering masih ada coupling	Lebih mudah per layer	Repository bisa di-mock
Feature-Based	Mudah — test file ada di dalam modul	Per-modul, terisolasi	Dependency injection membantu
Clean Architecture	Sangat mudah — Domain Entity adalah pure object, zero dependency	Hanya di layer Infrastructure	Port/interface memang dirancang untuk di-mock
Modular Monolith	Mudah — sama seperti Clean Architecture per modul	Module contract test lewat public API	Mock hanya lewat interface publik modul
Microservices	Mudah per service	Perlu contract testing antar service	Tiap service independen, tapi perlu mock service lain

Insight Kunci

Simple MVC — testing bisa dilakukan tapi menyakitkan. Biasanya berujung pada integration test berat karena logic tidak bisa dipisah dari HTTP dan DB.

Clean Architecture — satu-satunya yang dirancang secara eksplisit dengan testability sebagai tujuan utama. Domain layer bisa di-test 100% tanpa database, tanpa HTTP, tanpa framework apapun.

Microservices — membuka masalah baru: contract testing. Unit test per service mudah, tapi memastikan dua service bisa berkomunikasi dengan benar butuh tooling tambahan seperti PactNet (.NET) atau Pact.js (Node.js).

Jadi kalau testing adalah prioritas utama, pilihan arsitektur mengerucut ke Clean Architecture — dan semakin besar sistem, semakin besar keuntungannya.

---

Apa yang Sebenarnya Berkembang

Yang berkembang bukan folder-nya.

Yang berkembang adalah pemahaman manusia tentang kompleksitas software.

Folder hanya representasi dari cara berpikir engineering.

Dari sekadar rapikan file, menjadi kelola perubahan, tim, risiko, dan skala bisnis.

---

Apakah Struktur Modern Selalu Lebih Baik

Tidak.

Untuk project kecil, struktur sederhana sering kali lebih efektif.

Misalnya aplikasi internal kecil:

/controllers
/models

Sudah cukup.

Memaksakan arsitektur enterprise pada project kecil justru bisa menjadi overengineering — membuang waktu untuk setup infrastruktur yang tidak diperlukan, dan memperlambat iterasi di fase yang seharusnya cepat.

Tabel Panduan Singkat

Ukuran Tim	Kompleksitas	Arsitektur yang Tepat
1–2 orang	Rendah	Simple MVC
2–5 orang	Menengah	Layered
5–20 orang	Tinggi	Feature-Based
10–30 orang	Sangat Tinggi	Clean Architecture atau Modular Monolith
20–50 orang	Enterprise (single deployment)	Modular Monolith
50+ orang	Enterprise (distributed)	Microservices

---

Prinsip yang Benar

Gunakan struktur folder sesuai:

ukuran tim

kompleksitas bisnis

umur project

kecepatan perubahan fitur

skill developer yang memelihara

Bukan karena tren internet.

---

Kesimpulan

Ya, struktur folder berkembang seiring berkembangnya software engineering.

Perjalanan itu kurang lebih seperti ini:

> Simple MVC → Layered → Feature-Based → Clean Architecture → Modular Monolith → Microservices

Setiap tahap muncul untuk menjawab masalah pada tahap sebelumnya.

Folder structure bukan dekorasi.

Ia adalah jejak evolusi cara manusia membangun software yang semakin kompleks.

---

Penutup

Developer yang matang tidak bertanya:

> "Struktur folder terbaik apa?"

Tetapi bertanya:

> "Struktur apa yang paling tepat untuk masalah yang sedang saya hadapi?"

Itulah pola pikir engineering yang sesungguhnya.