Pendahuluan #

Dalam software engineering, keputusan arsitektur adalah keputusan paling mahal untuk diubah. Framework bisa diganti, library bisa di-refactor, bahkan bahasa pemrograman bisa dimigrasikan — tetapi arsitektur yang salah akan terus “menghantui” sistem selama bertahun‑tahun.

Architectural pattern hadir untuk membantu menjawab pertanyaan besar seperti:

• Bagaimana sistem dibagi menjadi komponen besar?
• Bagaimana komponen tersebut berkomunikasi?
• Di mana boundary antara domain, data, dan infrastruktur?
• Bagaimana sistem berevolusi ketika tim, traffic, dan kompleksitas meningkat?

Berbeda dengan design pattern (Repository, Factory, Strategy) yang bekerja di level kode, architectural pattern bekerja di level sistem. Ia menentukan shape dari aplikasi: bagaimana kode diorganisir, bagaimana dependency mengalir, dan bagaimana perubahan ditangani.

Artikel ini menyajikan daftar architectural pattern yang paling umum dan relevan di dunia software engineering modern, disertai konteks kapan pattern tersebut masuk akal digunakan — dan kapan justru menjadi beban.

Tujuannya bukan agar kamu menghafal semua pattern, melainkan:

memahami trade-off, use case, dan implikasi jangka panjang dari setiap pilihan arsitektur.

Daftar Architectural Pattern #

Section ini menyajikan daftar architectural pattern tanpa pengelompokan kategori, agar mudah dibaca sebagai referensi cepat. Setiap pattern dirangkum dalam satu paragraf singkat yang menekankan inti ide dan nilai utamanya.

Monolithic Architecture #

Ringkasan Arsitektur Sistem dibangun dan dideploy sebagai satu unit utuh. Semua komponen berada dalam satu codebase dan satu proses runtime, sehingga koordinasi dan deployment menjadi sangat sederhana.

Sejarah Singkat Ini adalah bentuk arsitektur paling awal dalam software engineering. Pada masa ketika sistem masih kecil dan tim terbatas, pendekatan ini adalah default dan paling rasional.

Modular Monolith #

Ringkasan Arsitektur Monolith yang dibagi ke dalam modul-modul dengan boundary tegas dan aturan dependency yang jelas, namun tetap dideploy sebagai satu unit.

Sejarah Singkat Muncul sebagai koreksi terhadap monolith besar yang tidak terstruktur dan sebagai respon atas adopsi microservices yang terlalu dini.

Layered Architecture #

Ringkasan Arsitektur Aplikasi dibagi ke dalam layer horizontal seperti presentation, application, domain, dan data, dengan alur dependensi yang biasanya satu arah.

Sejarah Singkat Populer sejak era enterprise application karena mudah dipahami dan mempermudah pembagian tanggung jawab antar tim.

Clean Architecture #

Ringkasan Arsitektur Business rule ditempatkan sebagai pusat sistem, dengan dependency yang selalu mengarah ke dalam untuk melindungi domain dari perubahan teknologi.

Sejarah Singkat Dipublikasikan oleh Robert C. Martin sebagai sintesis dari Hexagonal Architecture, Onion Architecture, dan prinsip-prinsip DDD.

Hexagonal Architecture (Ports & Adapters) #

Ringkasan Arsitektur Core application berinteraksi dengan dunia luar melalui port dan adapter, menciptakan boundary eksplisit antara business logic dan infrastruktur.

Sejarah Singkat Diperkenalkan oleh Alistair Cockburn untuk meningkatkan testability dan mengurangi coupling terhadap database, UI, dan framework.

Onion Architecture #

Ringkasan Arsitektur Domain model berada di pusat lapisan, dikelilingi oleh application dan infrastructure layer.

Sejarah Singkat Berkembang dari praktik Domain-Driven Design sebagai cara memvisualisasikan dependency yang selalu mengarah ke domain.

Service-Based Architecture #

Ringkasan Arsitektur Aplikasi dipecah menjadi beberapa service besar dengan komunikasi relatif sederhana, sering kali masih berbagi database.

Sejarah Singkat Muncul sebagai pendekatan pragmatis saat monolith mulai terlalu besar, tetapi organisasi belum siap dengan kompleksitas microservices.

Microservices Architecture #

Ringkasan Arsitektur Sistem terdiri dari banyak service kecil yang dapat dikembangkan, dideploy, dan diskalakan secara independen.

Sejarah Singkat Dipengaruhi oleh SOA dan dipopulerkan oleh perusahaan skala besar seperti Netflix, Amazon, dan Uber.

Event-Driven Architecture #

Ringkasan Arsitektur Komponen sistem berkomunikasi melalui event secara asynchronous menggunakan message broker atau event bus.

Sejarah Singkat Berkembang dari kebutuhan sistem terdistribusi yang memerlukan loose coupling dan throughput tinggi.

CQRS (Command Query Responsibility Segregation) #

Ringkasan Arsitektur Memisahkan model untuk operasi tulis (command) dan baca (query) guna mengelola kompleksitas dan kebutuhan scaling.

Sejarah Singkat Dipromosikan oleh Greg Young sebagai evolusi dari Domain-Driven Design dan Event Sourcing.

Serverless Architecture #

Ringkasan Arsitektur Logic aplikasi dijalankan tanpa mengelola server secara langsung, biasanya berbasis fungsi dan event.

Sejarah Singkat Muncul seiring berkembangnya cloud computing dan kebutuhan efisiensi operasional.

Microkernel (Plugin Architecture) #

Ringkasan Arsitektur Core system yang minimal dengan kemampuan diperluas melalui plugin atau extension.

Sejarah Singkat Digunakan sejak lama pada sistem extensible seperti operating system dan IDE.

MVC / MVP / MVVM #

Ringkasan Arsitektur Pola pemisahan concern di level UI antara state, logic, dan presentation.

Sejarah Singkat Berawal dari MVC di Smalltalk, kemudian berevolusi menjadi MVP dan MVVM untuk menjawab kebutuhan UI modern.

Kapan Menggunakan Architectural Pattern Tertentu? #

Section ini disajikan dalam bentuk tabel ringkas agar mudah di-scan, terutama saat melakukan diskusi arsitektur atau high-level design review.

Penutup #

Architectural pattern adalah alat berpikir, bukan checklist.

Arsitektur yang baik lahir dari:

• konteks bisnis
• ukuran tim
• dan kemampuan mengelola kompleksitas

Di bagian selanjutnya, kita akan membahas masing-masing pattern secara mendalam, lengkap dengan contoh nyata dan anti-pattern yang sering terjadi.