Proses ADR

Catatan keputusan arsitektur (ADR) adalah dokumen yang menjelaskan pilihan yang dibuat tim tentang aspek penting dari arsitektur perangkat lunak yang mereka rencanakan untuk dibangun. Setiap ADR menggambarkan keputusan arsitektur, konteksnya, dan konsekuensinya. ADR memiliki status dan karenanya mengikuti siklus hidup. Untuk contoh ADR, lihatapendiks.

Proses ADR menghasilkan koleksi catatan keputusan arsitektur. Koleksi ini membuat log keputusan. Log keputusan menyediakan konteks proyek serta informasi implementasi dan desain yang terperinci. Anggota proyek membaca berita utama masing-masing ADR untuk mendapatkan gambaran umum tentang konteks proyek. Mereka membaca ADR untuk menyelam jauh ke dalam implementasi proyek dan pilihan desain.

Ketika tim menerima ADR, itu menjadi tidak berubah. Jika wawasan baru memerlukan keputusan yang berbeda, tim mengusulkan ADR baru. Ketika tim menerima ADR baru, itu menggantikan ADR sebelumnya.

Lingkup proses ADR

Anggota proyek harus membuat ADR untuk setiap keputusan signifikan secara arsitektur yang memengaruhi proyek atau produk perangkat lunak, termasuk yang berikut ini (Richards dan Ford 2020):

• Struktur (misalnya, pola seperti layanan mikro)

• Persyaratan non-fungsional (keamanan, ketersediaan tinggi, dan toleransi kesalahan)

• Dependensi (kopling komponen)

• Antarmuka (API dan kontrak yang diterbitkan)

• Teknik konstruksi (perpustakaan, kerangka kerja, alat, dan proses)

Persyaratan fungsional dan non-fungsional adalah input yang paling umum untuk proses ADR.

Konten ADR

Ketika tim mengidentifikasi kebutuhan akan ADR, anggota tim mulai menulis ADR berdasarkan templat seluruh proyek. (LihatADRGitHuborganisasimisalnya template.) Template menyederhanakan pembuatan ADR dan memastikan bahwa ADR menangkap semua informasi yang relevan. Minimal, setiap ADR harus menentukan konteks keputusan, keputusan itu sendiri, dan konsekuensi dari keputusan untuk proyek dan hasilnya. (Untuk contoh bagian ini, lihatapendiks.) Salah satu aspek yang paling kuat dari struktur ADR adalah bahwa hal itu berfokus pada alasan keputusan daripada bagaimana tim mengimplementasikannya. Memahami mengapa tim membuat keputusan membuat lebih mudah bagi anggota tim lain untuk mengadopsi keputusan, dan mencegah arsitek lain yang tidak terlibat dalam proses pengambilan keputusan untuk mengesampingkan keputusan itu di masa depan.

Proses adopsi ADR

Setiap anggota tim dapat membuat ADR, tetapi tim harus menetapkan definisi kepemilikan untuk ADR. Setiap penulis yang merupakan pemilik ADR harus secara aktif memelihara dan mengkomunikasikan konten ADR. Untuk memperjelas kepemilikan ini, panduan ini mengacu pada penulis ADR sebagaiPemilik ADRdi bagian berikut. Anggota tim lain selalu dapat berkontribusi pada ADR. Jika konten ADR berubah sebelum tim menerima ADR, pemilik harus menyetujui perubahan ini.

Diagram berikut menggambarkan proses pembuatan, kepemilikan, dan adopsi ADR.

Setelah tim mengidentifikasi keputusan arsitektur dan pemiliknya, pemilik ADR memberikan ADR diDiusulkanmenyatakan pada awal proses. ADR diDiusulkannegara siap untuk ditinjau.

Pemilik ADR kemudian memulai proses peninjauan untuk ADR. Tujuan dari proses peninjauan ADR adalah untuk memutuskan apakah tim menerima ADR, menentukan bahwa perlu pengerjaan ulang, atau menolak ADR. Tim proyek, termasuk pemiliknya, meninjau ADR. Rapat peninjauan harus dimulai dengan slot waktu khusus untuk membaca ADR. Rata-rata, 10 hingga 15 menit sudah cukup. Selama waktu ini, setiap anggota tim membaca dokumen dan menambahkan komentar dan pertanyaan untuk menandai topik yang tidak jelas. Setelah fase peninjauan, pemilik ADR membacakan dan mendiskusikan setiap komentar dengan tim.

Jika tim menemukan titik tindakan untuk meningkatkan ADR, status ADR tetapDiusulkan. Pemilik ADR merumuskan tindakan, dan, bekerja sama dengan tim, menambahkan penerima tugas untuk setiap tindakan. Setiap anggota tim dapat berkontribusi dan menyelesaikan poin tindakan. Adalah tanggung jawab pemilik ADR untuk menjadwal ulang proses peninjauan.

Tim juga dapat memutuskan untuk menolak ADR. Dalam hal ini, pemilik ADR menambahkan alasan penolakan untuk mencegah diskusi di masa mendatang tentang topik yang sama. Pemilik mengubah status ADR menjadiDitolak.

Jika tim menyetujui ADR, pemilik menambahkan stempel waktu, versi, dan daftar pemangku kepentingan. Pemilik kemudian memperbarui status keDiterima.

ADR dan log keputusan yang mereka buat mewakili keputusan yang dibuat oleh tim dan memberikan riwayat semua keputusan. Tim menggunakan ADR sebagai referensi selama kode dan tinjauan arsitektur jika memungkinkan. Selain melakukan tinjauan kode, tugas desain, dan tugas implementasi, anggota tim harus berkonsultasi dengan ADR untuk keputusan strategis untuk produk.

Diagram berikut menunjukkan proses penerapan ADR untuk memvalidasi jika perubahan komponen perangkat lunak sesuai dengan keputusan yang disepakati.

Sebagai praktik yang baik, setiap perubahan perangkat lunak harus melalui tinjauan sejawat dan memerlukan setidaknya satu persetujuan. Selama peninjauan kode, peninjau kode mungkin menemukan perubahan yang melanggar satu atau lebih ADR. Dalam hal ini, pengulas meminta penulis perubahan kode untuk memperbarui kode, dan membagikan tautan ke ADR. Ketika penulis memperbarui kode, itu disetujui oleh peer reviewer dan digabungkan ke dalam basis kode utama.

Proses peninjauan ADR

Tim harus memperlakukan ADR sebagai dokumen yang tidak dapat diubah setelah tim menerima atau menolaknya. Perubahan pada ADR yang ada memerlukan pembuatan ADR baru, menetapkan proses peninjauan untuk ADR baru, dan menyetujui ADR. Jika tim menyetujui ADR baru, pemilik harus mengubah status ADR lama menjadiDigantikan. Diagram berikut menggambarkan proses pembaruan.