- Model C4 adalah pendekatan yang ramah bagi developer untuk membuat diagram arsitektur perangkat lunak, sehingga struktur yang kompleks bisa dilihat dengan membaginya secara bertahap
- Abstraksi diturunkan secara hierarkis dalam urutan software systems → containers → components → code
- Diagram juga disusun mengikuti struktur system context → container → component → code
- Sesuai kebutuhan, diagram system landscape, dynamic, dan deployment melengkapi perspektif struktur keseluruhan serta sudut pandang eksekusi dan deployment
- Ini adalah pendekatan notation independent dan tooling independent yang tidak terikat pada notasi atau alat tertentu, sehingga bisa diterapkan sesuai lingkungan yang sudah ada
Komposisi Model C4
- Model C4 adalah model untuk memvisualisasikan arsitektur perangkat lunak, dan dibuat oleh Simon Brown
- Intinya terletak pada penggunaan abstraksi hierarkis dan diagram hierarkis secara bersamaan
Diagram dan Independensi
- Diagram dasar disusun agar arsitektur dapat dilihat pada kedalaman yang berbeda-beda
- Diagram pendukung melengkapi sudut pandang yang tidak cukup terwakili hanya dengan lapisan dasar
- Model ini notation independent dan tooling independent, sehingga tidak memaksakan pilihan notasi atau alat tertentu
- Sebagai materi terkait, ada video Visualising software architecture with the C4 model yang direkam pada “Agile on the Beach 2019” bulan Juli 2019 dan materi The C4 model
1 komentar
Opini Hacker News
Menurut saya, masalah terbesar diagram arsitektur adalah ia tidak selaras dengan codebase.
Diagram seperti ini perlu dibuat otomatis. Kalau tidak, tim tidak punya cara untuk tahu apakah gambar yang sedang dilihat benar-benar menggambarkan kondisi terbaru sistem.
Diagram menunjukkan sudut pandang tertentu; sebagian karakteristik ditekankan dan sebagian lain dihilangkan. Untuk objek yang sama pun bisa ada beberapa diagram yang menjelaskan aspek atau skenario yang berbeda. Pada akhirnya, diagram juga harus dipelihara bersama kode dan arsitektur aplikasi seperti dokumen teks, dan tidak ada pilihan selain menjadikannya pekerjaan rutin dalam manajemen perubahan.
Di banyak proyek, kode tidak disusun dengan cara yang sama seperti model di kepala kita, dan hampir semua bahasa tidak menyediakan cara untuk mengatasinya. Menandainya lewat komentar di kode pun memiliki masalah yang sama dengan menjaga diagram, komentar, dan dokumentasi tetap mutakhir.
Ia merepresentasikan kondisi target, bukan kondisi saat ini. Kode harus mengikuti diagram, bukan sebaliknya. Membuat diagram dari kode baru masuk akal sebatas membantu orang yang baru bergabung ke proyek tanpa dokumentasi; itu pun biasanya dibuat sekali, lalu dibersihkan dari noise, dirapikan, dan setelah itu dipakai sebagai dokumen acuan.
Diagram tingkat tinggi harus bisa dibuat cepat dan dibuang cepat, dan apa yang dihilangkan sama pentingnya dengan apa yang ditampilkan.
Saya suka C4. Dulu saya menganggap diagram konteks seperti “User -{do their job}-> System-of-Record” tidak berguna, tapi sekarang saya paham alasannya.
Saya sedang mengerjakan desain baru untuk sistem yang kompleks bersama tim-tim yang diperluas menggunakan C4. Saat menggambar diagram tingkat teratas kali ini, saya menyadari bahwa selain UI web ada juga aplikasi mobile yang bisa saja setengah terputus, sehingga ketika offline atau backend lambat, jika hasil tertentu belum tersedia, beberapa perilaku harus diturunkan kualitasnya secara elegan. Ini kemudian mengarah ke antrean kerja di lapisan berikutnya, lalu kembali ke UX, sehingga kami bisa menyatakan dengan jelas permintaan mana yang penyelesaiannya bisa memakan waktu tak terbatas. Mungkin pada akhirnya kami akan sampai ke sana juga, tetapi analisis ini menempatkan masalah tersebut tepat di depan mata. Semua itu karena kami harus menggambar “Remote-User --{Mobile Stuff}--> Backend”. Alat apa pun tidak masalah; saya, misalnya, memakai tab terpisah per lapisan di draw.io. Jika sudah lebih konkret, lapisan yang lebih rendah akan saya pisahkan ke file tersendiri.
Saya juga memahami argumen bahwa diagram tidak membutuhkan sistem yang diformalkan, tetapi menurut saya C4 cukup ringan. Saya tidak sampai turun ke level kode.
Meski begitu, structurizr, yang menghasilkan diagram C4, sangat meningkatkan produktivitas saya. Pendekatan membuat beberapa tampilan dengan tingkat detail berbeda dari satu model itu bagus, dibandingkan mermaid atau plantuml dan sejenisnya, yang membuat tiap diagram harus terus mendefinisikan dan mendefinisikan ulang komponen yang sama secara terpisah. Alur membuat branch, memodifikasi model, lalu mempresentasikan ide sangat cocok bagi saya.
Tidak ada cara untuk menggambar konsep yang tidak secara ketat termasuk dalam C4. Misalnya, saya ingin memasukkan dua komponen ke dalam satu kotak untuk menunjukkan bahwa saat ini keduanya dideploy sebagai satu layanan, tetapi itu tidak mungkin. Bukan berarti itu desain yang benar-benar baik, tetapi akan membantu tim memahaminya. Gagasan mendeskripsikan arsitektur secara formal itu bagus, tetapi kurangnya kustomisasi pada keluaran diagram terasa sangat menyulitkan.
Kita mendeskripsikan arsitektur, lalu structurizr merender diagramnya.
Memang bisa, tetapi cukup merepotkan, dan jika deskripsi panah di antara kotak menjadi panjang, tata letak otomatis cepat berantakan.
Saya cenderung melihat arsitektur perangkat lunak sebagai kumpulan keputusan desain yang mengarahkan implementasi
Berdasarkan pengalaman saya, kebanyakan arsitek perangkat lunak memberikan panduan dan struktur kepada software engineer. Namun kalimat dalam penjelasan C4, “membuat peta kode yang sudah ada pada berbagai tingkat detail,” terdengar berbeda. Saya tidak mengerti mengapa diagram kode disebut arsitektur perangkat lunak. Itu secara harfiah berada di level kode; bagaimana bisa itu arsitektur? Mirip seperti memasukkan diagram rangkaian di dalam colokan ke cetak biru rumah. Kalau “harus memakai alat otomatisasi”, apakah maksudnya mendokumentasikan codebase yang sudah ada per fungsi? Saya tidak melihat bagaimana itu berguna untuk merancang dan merencanakan perangkat lunak. Peta yang menjelaskan struktur perangkat lunak yang sudah ada bisa saja keren, tetapi saat membicarakan design pattern, kita tidak memberikan peta implementasi singleton per fungsi. Cukup katakan bahwa kita membutuhkan singleton atau repository pattern. Desain perangkat lunak itu sendiri jelas ada dan pendekatan seperti ini tampak valid untuk desain, tetapi berdasarkan pengalaman saya, desain, implementasi, dan arsitektur perangkat lunak tidak sama, dan tidak dikerjakan oleh orang yang sama pula. Ini terlihat lebih dekat ke desain sistem, dan arsitek perangkat lunak mungkin berperan memberi saran agar desain sistem itu sesuai dengan prinsip arsitektur yang baik. Mungkin saya terlalu mempermasalahkannya
Menurut saya, peran penting arsitektur perangkat lunak adalah memberi informasi agar developer bisa membuat keputusan desain sendiri tanpa setiap kali menyerahkan penilaian kepada otoritas. Namun, batas antara di mana arsitektur berakhir dan pengembangan dimulai sangat bervariasi. Saya pikir arsitektur itu sendiri menentukan apa yang penting dari sudut pandang arsitektur. Jika arsitektur menilai suatu detail aplikasi level rendah itu penting, maka itu juga menjadi detail arsitektur. Dalam praktiknya, di sebagian besar organisasi, arsitektur setidaknya mengendalikan desain tingkat atas seperti komponen, pola komunikasi, API, dan teknologi yang digunakan. Di sebagian organisasi, bahkan sampai ke kelas individual. Bukan semua kelas, melainkan kelas yang memodelkan domain masalah, terutama ketika model itu dipakai sebagai bahasa lintas proyek atau diimplementasikan sebagai artefak bersama. C4 cocok untuk organisasi yang melihat struktur level lebih rendah, bukan hanya daftar aplikasi dan antarmuka integrasi, sebagai perhatian arsitektur
Pada dasarnya, ini berarti memiliki diagram untuk setiap level dalam sistem yang jelas khas atau berguna. Jika Anda membutuhkan diagram level kode, besar kemungkinan Anda sedang mengerjakan pekerjaan kustom yang kompleks, atau Anda terlalu banyak menspesifikasikan desain yang sebenarnya bisa dibiarkan sebagai detail implementasi
Mirip seperti dalam konstruksi properti di dunia nyata, peran arsitek, insinyur, dan penanggung jawab lapangan berbeda. Saya penasaran di mana sebaiknya garis ditarik dalam arsitektur, desain, dan implementasi, serta perhatian apa saja yang harus ditangani masing-masing
Menarik, tetapi sulit melihatnya sebagai sesuatu yang benar-benar menambahkan banyak hal
Diagram tingkat tinggi itu bagus, tetapi kita sudah bisa membuatnya tanpa membaca situs web model visual yang keren. Situs itu sendiri pada dasarnya mengakui hal ini. Pernyataan bahwa ada UML, ArchiMate, dan SysML di industri, tetapi banyak tim memilih diagram “kotak dan garis” yang jauh lebih sederhana, sangat tepat. Namun tampaknya mereka mengabaikan mengapa diagram kelas UML gagal total. Mereka mengakui bahwa tidak ada yang menyukainya, tetapi C keempat dari model ini, yaitu kode, pada akhirnya adalah diagram kelas UML. Kita tidak membutuhkan hal seperti itu. Cukup buat diagram apa pun dengan jelas dan beri label pada panahnya. Tiga diagram pertama justru merupakan contoh yang bagus untuk itu
Saat memikirkan konsep baru atau brainstorming, ini sangat membantu karena alatnya tidak menghambat. Sekarang saya memakai Freeform; sangat sederhana tetapi berfungsi dengan baik. Tinggal pilih dua objek, lalu cmd-klik atau klik kanan dan tekan “add connecting line”
Baru beberapa bulan lalu saya juga menyelesaikan lagi dokumen arsitektur yang berisi cukup banyak diagram kelas, diagram sekuens, dan use case
Kotak-kotak mudah berakhir sebagai campuran hal-hal dari level yang berbeda. Ada yang abstrak, ada yang konkret, dan ada yang sekadar arbitrer. Jadi, misalnya ketika harus menyusun potongan arsitektur yang lebih besar seperti rantai pasok, pada dasarnya semuanya harus dikerjakan ulang. Banyak pemborosan, dan tidak ada cukup orang yang melihat keseluruhan arsitektur dengan cukup jelas, sehingga menimbulkan pemborosan lain dan masalah kualitas. Anehnya, banyak engineer bereaksi defensif terhadap pendekatan yang lebih formal; mungkin karena tidak ada manfaat langsung, atau karena belum pernah menangani arsitektur skala besar sehingga tidak melihat masalahnya
Ini menunjukkan bahwa rekayasa perangkat lunak masih merupakan bidang yang belum matang
Dalam kasus saya, sudah lebih dari 25 tahun, tetapi kita masih membahas hal yang sama yang mendekati “dasar”. Bukan berarti ini buruk, tetapi kemajuannya lambat, dan tidak bisa semata-mata disalahkan pada perusahaan tertentu, konsorsium tertentu, atau kepentingan komersial
Seberapa sering Anda kesulitan memahami apa yang ingin dikatakan seseorang karena dalam satu pemikiran ia terus naik turun antara detail yang tinggi, kompleksitas yang tinggi, dan kesederhanaan dari kejauhan? Masalah yang sama muncul ketika developer berpikir, “tinggal gambar kotak dan panah secukupnya di papan ini; karena masuk akal di kepala saya, berarti ini diagram yang bagus”
Bahkan orang yang bukan insinyur sipil pun bisa langsung memahami dan merasa denah lantai itu berguna
Namun, meskipun saya seorang software engineer profesional, diagram contoh ini tidak tampak cukup berguna atau informatif untuk sepadan dengan usaha yang dibutuhkan. Kode terlalu multidimensional sehingga sulit didekati dengan gambar dua dimensi, dan hasilnya tidak bekerja dengan baik. Yang mungkin punya potensi adalah pola kode arsitektur yang lebih terkonvensi. Hal-hal seperti structured concurrency, dan mungkin sesuatu pada level yang lebih tinggi lagi
Denah lantai memiliki konteks yang sangat tetap dan cakupan yang terbatas. Misalnya, tidak perlu menjelaskan jendela. Namun dalam perangkat lunak, kebanyakan “jendela” benar-benar harus dijelaskan. Karena semua “jendela” atau elemen berbeda satu sama lain, kita tidak bisa sekadar mengatakan ini adalah jendela lalu menyalinnya 20 kali
Jika model C4 terasa terlalu arbitrer dan terlalu dispesifikasikan, awal tahun ini saya menulis tentang praktik alternatif: https://www.ilograph.com/blog/posts/concrete-diagramming-mod...
Saya menyukai model ini, dan pernah juga harus memakai UML dalam arsitektur keamanan. Sebab di bidang itu, konsistensi dari konteks tingkat tertinggi hingga kode adalah kuncinya
Kesederhanaan model C4 adalah semacam mekanisme pemaksa. Jika ada konteks atau komponen tersembunyi, itu harus terlihat di dalam model. Jika bahkan terhadap sesuatu yang sesederhana ini ada resistensi, saya menganggapnya sebagai tanda bahwa mungkin ada elemen tersembunyi. Dalam proyek besar, elemen seperti itu umumnya memang ada. Ketika orang dibuat memperjelas cara berpikir mereka dengan cara ini, alih-alih sekadar menyisakan hak untuk mengusulkan dan mengkritik, mereka jadi berkomitmen pada pernyataan dan ide, sehingga kewenangan tersebar. Resistensi terhadap hal ini juga bisa muncul cukup besar. Namun ini bukan masalah pada modelnya, melainkan sesuatu yang terjadi ketika model bertemu dengan manusia. Karena saya menyukai konsistensinya, saya rasa saya akan memakai pendekatan seperti ini sebagai rujukan untuk desain keamanan
C4 sangat menarik dan menurut saya menangani masalah tertentu dalam arsitektur perangkat lunak dengan baik
Ia mengalihkan lapisan bawah arsitektur, yaitu terutama perangkat keras dan perangkat lunak sistem, ke abstraksi yang luas, lalu membuat kita memusatkan upaya pada hal-hal di stack di atasnya. Ini sangat cocok dengan pendekatan masa kini yang berbasis cloud, terkontainerisasi, dan skalabel. Terkait itu, ArchiMate juga bagus dan banyak bagian yang tumpang tindih, tetapi lebih berpijak kuat pada sisi infrastruktur. Dulu saya pernah memakai pendekatan diagram yang mirip ArchiMate untuk mengurangi benturan antara sistem dan sumber data, serta untuk menunjukkan bagaimana hal-hal yang kami beli dan integrasikan mendukung kebutuhan bisnis tertentu dan alur kerja pengguna; hasilnya sangat efektif. Pernyataan bahwa hal-hal seperti ini bisa menyimpang dari codebase sepenuhnya benar. Namun ketika harus menganalisis sistem yang kompleks atau menyampaikan sistem dan rencana kepada kelompok yang lebih besar, ini bisa menjadi alat yang sangat baik. Mengejutkan betapa seringnya tidak ada dokumentasi yang padu sama sekali, dan hanya dengan duduk selama beberapa minggu menggambar kotak dan garis penghubung, pekerjaan yang sebelumnya buntu dan membuat frustrasi bisa terurai dan menjadi lebih sederhana. Terutama ketika beberapa tim bekerja di area yang sama. C4, ArchiMate, UML, dan sejenisnya hanyalah bahasa diagram yang dibatasi untuk menangkap hal-hal tertentu yang ingin disampaikan, dianalisis, dan dicatat. Saya rasa mereka tidak terlalu bagus sebagai alat perencanaan awal atau desain. Banyak orang menderita pada masa tren besar UML. Saat itu seolah-olah organisasi kepala arsitek harus menguraikan setiap aspek sistem sampai definisi kelas dengan detail yang menyakitkan sebelum satu baris kode pun ditulis, dan kegilaan seperti “tinggal hasilkan kode dari diagram” menyiksa banyak orang. Begitu coding sesungguhnya dimulai, ribuan jam perencanaan itu biasanya diabaikan, dan para developer pada akhirnya melakukan apa yang mereka inginkan