Belajar Software Architecture and Design Patterns - Capstone: Sistem Order Management End-to-End | Belajar Software Architecture and Design Patterns

#Pendahuluan

Empat puluh sembilan konsep telah kalian pelajari — kini saatnya membuktikan mereka bisa tinggal serumah dalam satu sistem. Capstone ini bukan aplikasi demo kecil: ia adalah Order Management System yang dibangun bertahap (bukan big design up front), mengikuti urutan evolusi yang sama dengan urutan episode — karena itulah cara arsitektur tumbuh di dunia nyata.

#Peta Evolusi Lima Tahap

100%

Setiap tahap punya pemicu kebutuhan (bukan mode): tahap 1 karena kode mulai rapi; tahap 2 karena file saling menyentuh; tahap 3 karena invarian bocor; tahap 4 karena query list lambat; tahap 5 karena side-effect menahan response checkout.

#Struktur Akhir Proyek

src/
  domain/order/          # aggregate Order, Money VO, events, errors
  application/
    command/             # PlaceOrder/AddItem/CancelOrder handlers
    query/               # ListOrders handler -> read store
    port/out/            # OrderRepo, EventPublisher (interface)
  infrastructure/
    persistence/         # PostgresOrderRepository, mapper
    messaging/           # RabbitPublisher + outbox relay
    projection/          # projector OrderPlaced -> orders_read
  presentation/http/     # controller tipis + DTO
test/                    # unit domain / use case / integration
docker-compose.yml       # postgres + rabbitmq

cmd/server/main.go           # wiring DI eksplisit
internal/
  domain/order/              # aggregate struct + events
  app/command/               # PlaceOrderHandler dkk.
  app/query/                 # ListOrdersHandler
  adapter/postgresrepo/      # implement repo interface
  adapter/natsmq/            # publisher + relay goroutine
  httpapi/                   # router Fiber + DTO mapping
pkg/money/                   # VO uang reusable
migrations/                  # schema + tabel orders_read
docker-compose.yml           # postgres + nats

app/
  Domain/Order/              # Order entity murni + Money + events
    Action/                  # PlaceOrderAction, CancelOrderAction
    Query/                   # ListOrdersQuery (read model)
    Contract/                # interface repository & publisher
  Infrastructure/
    Persistence/Eloquent/    # repo impl + model mapper
    Messaging/               # broker + OutboxRelay command
    Projection/              # listener penulis orders_read
app/Http/Controllers/        # controller 4 baris
routes/api.php               # hanya routing
database/migrations/         # orders + events + outbox + orders_read
docker-compose.yml           # postgres + rabbitmq

Perhatikan kesamaan anatomi ketiganya: domain di tengah, application sebagai orkestrator, infrastructure mengimplementasikan port, presentation paling luar. Framework berbeda, arsitektur sama — itu tujuan utuh series ini.

#Infrastruktur Lokal

docker-compose.yml (identik ketiga lab)

services:
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_PASSWORD: dev
      POSTGRES_DB: orders
    ports: ["5432:5432"]
    volumes: [pgdata:/var/lib/postgresql/data]
  broker:
    image: rabbitmq:3-management     # ganti nats:2 untuk lab Go
    ports: ["5672:5672", "15672:15672", "4222:4222"]
volumes:
  pgdata:

#Real-World Implementasi

Karena seluruh pola sudah dikodekan di ep.10–22, bagian ini merangkai jalur integrasi end-to-end — contoh dari NestJS; padanannya sudah kalian miliki:

Alur lengkap satu request checkout (NestJS)

// POST /orders
@Controller('orders')
export class OrdersController {
  constructor(private bus: CommandBus) {}
  @Post()
  create(@Body() dto: CreateOrderDto) {        // validasi DTO (ep.8)
    return this.bus.execute(PlaceOrder.from(dto)); // command (ep.20)
  }
}
// PlaceOrderHandler:
//   1. Order.place(...)          -> invarian dijaga aggregate (ep.19)
//   2. transaction:
//        ordersRepo.save(order)  -> adapter Postgres (ep.9)
//        outbox.append(events)   -> atomik dengan data (ep.22)
//   3. relay -> publish OrderPlaced (ep.21)
//   4. subscribers: mailer kirim receipt, stats increment
// GET /orders?customerId=...  -> query langsung orders_read (ep.20)

Note

Jika kalian membangun capstone ini sendiri sambil membaca ulang episode terkait setiap tahap, satu sistem kecil ini merekap 24 episode sebelumnya — portofolio terkuat yang bisa ditunjukkan pada interview backend senior.

#Praktik

Target outline: bangun capstone bertahap dengan acceptance criteria per tahap, lalu bandingkan ketiga stack.

TAHAP 1 - LAYERED (commit: "capstone t1")
  [ ] POST /orders + GET /orders/:id jalan via service layer
  [ ] Controller < 10 baris; SQL hanya ada di repository
 
TAHAP 2 - MODULAR (commit: "capstone t2")
  [ ] Modul orders/users/billing terpisah, exports eksplisit
  [ ] dependency-cruiser / grep gate: modul tak saling borong internal
 
TAHAP 3 - HEXAGONAL + DDD (commit: "capstone t3")
  [ ] Aggregate Order menjaga invarian (locked, kosong, cancel)
  [ ] Port di application; infra mengimplementasikan; arch test hijau
 
TAHAP 4 - CQRS (commit: "capstone t4")
  [ ] orders_read + proyeksi dari OrderPlaced
  [ ] Benchmark list 100k baris: sebelum vs sesudah (catat angka!)
 
TAHAP 5 - EDA + OUTBOX (commit: "capstone t5")
  [ ] mailer-consumer + stats-consumer independen
  [ ] Uji matikan-broker-saat-checkout: tidak ada event hilang
 
RILIS v1.0 (tag: v1.0.0)
  [ ] docker compose up -> satu perintah hidupkan semuanya
  [ ] README: diagram arsitektur + cara run + hasil benchmark

| Metrik                     | NestJS | Fiber (Go) | Laravel |
|----------------------------|--------|------------|---------|
| Total LOC (domain+app)     |  ____  |    ____    |  ____   |
| Jumlah test                |  ____  |    ____    |  ____   |
| Durasi suite unit (s)      |  ____  |    ____    |  ____   |
| p95 POST /orders (ms)*     |  ____  |    ____    |  ____   |
| p95 GET list 100k (ms)*    |  ____  |    ____    |  ____   |
| Waktu build container (s)  |  ____  |    ____    |  ____   |
*) oha/hey: 1000 request, concurrency 50, lokal
 
Pertanyaan refleksi (tulis jawabanmu di README):
1. Di stack mana invarian domain paling enak diekspresikan? Kenapa?
2. Bagian mana dari Go yang memaksa eksplisit vs TS yang otomatis?
3. Kalau tim kamu 3 orang, tahap berapa cukup? Bukti?

Tip

Kriteria "selesai" yang jujur: orang lain bisa git clone + docker compose up + baca README 5 menit lalu sistem jalan tanpa bertanya. Uji dengan teman sesungguhnya.

#Penutup

Rangkuman episode ini:

Capstone = evolusi lima tahap dengan pemicu kebutuhan nyata, bukan penerapan semua pola sekaligus.
Ketiga framework bermuara pada anatomi identik: domain tengah, port/adapter, presentasi terluar.
Perbandingan akhir berbasis data benchmark + refleksi DX melengkapi README portofolio.

Episode 26 menengok ke depan: Tren Arsitektur Modern 2026 — platform engineering, serverless-first, WebAssembly di backend, dan dampak AI-assisted coding terhadap cara kita merancang sistem. Sampai jumpa!