Belajar Software Architecture and Design Patterns - Modular Architecture (Modular Monolith)

#Pendahuluan

Layered (episode 13) memberi disiplin teknologi tapi membiarkan domain bercampur: service orders bebas membaca tabel billing, controller users mengimpor repo products. Modular Monolith menambahkan dimensi yang hilang itu: sistem tetap satu deployment, namun di dalamnya hidup modul-modul dengan batas tegas.

Pola ini adalah jawaban industri 2026 atas "microservices hangover" — dan fondasi terbaik jika kelak memang perlu microservices (episode 26 membahas trennya).

#Konsep

#Package by Feature vs by Layer

BY LAYER (ep.13):              BY FEATURE/MODULE (ep.14):
├── controllers/               ├── users/
│   ├── OrdersController.ts    │   ├── api/        # public API modul
│   └── UsersController.ts     │   ├── internal/   # detail tersembunyi
├── services/                  │   └── domain/
│   ├── OrderService.ts        ├── orders/
│   └── UserService.ts         │   ├── api/
├── repositories/              │   ├── internal/
│   ...                        │   └── domain/
                               ├── products/ ...
Kohesi per TEKNOLOGI           Kohesi per DOMAIN/BISNIS

Aturan modular monolith: package by feature di level atas, layered DI DALAM tiap modul. Modul orders berisi layer sendiri; yang dipertukarkan antar modul hanya lewat gerbang publiknya.

#Module Boundary & Public API Antar Modul

Tiga aturan boundary:

1. Public API eksplisit — modul lain hanya boleh memanggil apa diekspos barrel/interface (orders/api/index.ts, package ordersapi di Go).
2. Internal tertutup — internal/ tidak diimpor lintas modul; pelanggaran = coupling tersembunyi.
3. Komunikasi — sinkron via public API (panggilan method), asinkron via event (domain events, ep.19/21) untuk decoupling lebih kuat.

#Data Isolation Per Modul

Aturan paling keras sekaligus paling bernilai: modul lain dilarang menyentuh tabel milik modul. Ingin data order? Minta lewat API modul orders atau langganan event-nya — jangan query langsung tabel orders. Isolasi inilah yang membuat ekstraksi ke microservices kelak tinggal "angkat satu folder + ganti panggilan lokal jadi RPC".

#Real-World Implementasi

// src/orders/orders.module.ts
@Module({
  imports: [DatabaseModule],
  controllers: [OrdersController],
  providers: [CheckoutService, PrismaOrdersRepository],
  exports: [CheckoutService],   // SATU-SATunya yang bocor keluar
})
export class OrdersModule {}
 
// src/orders/index.ts - PUBLIC API modul:
export { CheckoutService } from './services/checkout.service';
export { PlaceOrderCommand } from './api/place-order.command';
// TANPA export PrismaOrdersRepository/entity internal!
 
// src/users/services/register-user.service.ts
constructor(
  private checkout: CheckoutService, // via import dari '@app/orders'
) {}

internal/
├── orders/          # modul utuh
│   ├── public.go    # kontrak publik: type CheckoutService interface
│   ├── checkout.go  # implementasi internal
│   ├── repository.go
│   └── domain.go
├── users/
│   ├── public.go    // func NewService(orders orders.PublicAPI) *Service
│   └── ...
├── products/...
└── billing/...
# Go compiler menegakkan: hanya identifier kapital yang bisa diimport
# lintas package - bahasa memaksa public API minimalis.

Modules/
├── Orders/
│   ├── Http/Controllers/
│   ├── Services/CheckoutService.php
│   ├── Repositories/
│   ├── Domain/
│   └── Routes/api.php          # rute milik modul sendiri
├── Users/ ...
└── Billing/ ...
// Aturan tim: antar modul HANYA via interface di Modules/*/Contracts.

#Praktik

Target outline: pecah monolit layered menjadi 4 modul — users, orders, products, billing — komunikasi via public API.

1. Buat skeleton 4 modul (folder + file public API kosong)
2. Pindahkan kode fitur ke modulnya masing-masing
   (git mv agar riwayat ikut!)
3. Petakan dependency lintas-fitur lama:
   grep -rn "from '.*users'" src/orders -> ganti jadi import public API
4. Tegakkan aturan tabel:
   - billing TIDAK BOLEH query tabel orders
   - kebutuhan data order? panggil orders.PublicAPI atau subscribe event
5. Lint gate baru (dependency-cruiser): dilarang import
   */internal/* atau */domain/* dari modul lain
6. Suite hijau + commit "ep14: split into modules"

forbidden: [
  {
    name: 'no-cross-module-internals',
    from: { path: '^src/(users|products|billing)/' },
    to: { path: '^src/orders/(internal|domain|repositories)' },
  },
],

Ujian akhir: coba bayangkan modul orders diekstrak jadi microservice — karena semua komunikasinya sudah via public API/event, daftar perubahannya pendek. Itu bukti modular monolith kalian benar.

#Penutup

Rangkuman episode ini:

• By feature di luar, by layer di dalam; public API eksplisit, internal tertutup.
• Data isolation per modul adalah aturan paling bernilai untuk masa depan microservices.
• Praktik: monolit layered dipecah 4 modul dengan gerbang lint; Go compiler membantu via kapitalisasi & internal/.

FASE 3 tuntas! Episode 15 membuka FASE 4 advanced: Hexagonal Architecture (Ports & Adapters) — domain di tengah, plug-in/plug-out infrastruktur, dan swap Postgres→in-memory untuk testing. Sampai jumpa!