Mengapa Saya Berhenti Menulis Kode dan Mulai Mendesain
Dulu saya berpikir bahwa pengembangan perangkat lunak berarti menulis fitur. Saya pikir tugas saya adalah membuat entitas, membangun controller, dan menghubungkan basis data.
Sebuah proyek baru-baru ini mengubah perspektif saya. Saya belajar bahwa pengodean hanyalah satu bagian dari solusi. Pekerjaan yang sebenarnya terjadi sebelum Anda menulis satu baris kode pun.
Anda harus memutuskan arsitekturnya. Anda harus bertanya mengapa itu cocok, berapa biayanya, dan risiko apa yang diselesaikannya.
Berikut adalah pelajaran utama saya:
• Arsitektur harus sesuai dengan tahap produk. Sangat menggoda untuk langsung menggunakan microservices, Kubernetes, dan antrean event yang kompleks. Untuk proyek kami, kami memilih arsitektur berlapis (layered architecture) dalam satu proses tunggal. Hal ini memungkinkan kami untuk memisahkan tanggung jawab tanpa kerumitan sistem terdistribusi. Sesuatu yang sederhana sering kali lebih baik saat Anda baru memulai.
• Beberapa keputusan terasa murah sekarang tetapi mahal di kemudian hari. Kami menambahkan TenantId ke dalam model data kami sejak hari pertama. Meskipun kami hanya memiliki satu klien, hal ini memudahkan transisi ke model SaaS di masa mendatang. Jika Anda menunggu terlalu lama untuk menambahkan multi-tenancy, migrasinya akan menjadi mimpi buruk.
• Desain mencegah jalan buntu di masa depan. Pemrograman menyelesaikan masalah yang mendesak. Desain menyelesaikan masalah tanpa menutup pintu bagi masa depan. Kami menggunakan container sejak dini untuk memudahkan perpindahan ke infrastruktur yang berbeda. Kami menggunakan interface untuk mempermudah penggantian penyedia layanan.
• Perubahan bisnis mendorong perubahan teknis. Sebuah sistem beralih ke microservices karena bisnis berkembang. Sebuah aplikasi klinik tunggal menjadi platform SaaS untuk ratusan klinik. Pergeseran ini mengubah cara Anda menangani penagihan, langganan, dan penskalaan (scaling).
• Keandalan membutuhkan pola yang cerdas. Kami beralih dari panggilan sinkron (synchronous calls) ke arsitektur berbasis event (event-driven architecture). Dalam sistem medis, layanan notifikasi yang lambat tidak boleh menyebabkan kegagalan pada pemesanan janji temu. Kami menggunakan pola Outbox untuk memastikan data tetap aman meskipun message broker mengalami kegagalan.
• Pola harus sesuai dengan domain. Jangan gunakan pola secara membabi buta. Diagnosis medis membutuhkan konsistensi yang kuat (strong consistency). Anda tidak dapat mengandalkan eventual consistency demi keselamatan pasien. Jangan gunakan cache untuk data klinis yang sensitif jika hal itu merusak jejak audit (audit trail) Anda.
• DevOps bukanlah pemikiran belakangan. Deployment, pemeriksaan kesehatan (health checks), dan pipeline adalah bagian dari desain awal. Anda harus memperkirakan biaya dan memilih komponen yang benar-benar melayani kebutuhan Anda.
Perbedaan antara seorang programmer dan seorang desainer adalah "mengapa."
Seorang programmer bertanya: "Bagaimana cara membuat ini berfungsi?" Seorang desainer bertanya: "Mengapa ini merupakan solusi yang tepat untuk masalah spesifik ini?"