- Klaim bahwa sebagian besar tantangan inti dalam pengembangan perangkat lunak muncul bukan di dalam kode, melainkan pada boundary tempat kode bertemu kode lain, dan sistem bertemu sistem
- Boundary = titik tempat kepentingan, tanggung jawab, dan konteks yang berbeda saling bertemu
- Pemisahan fungsi, modularisasi, microservices, dan hampir semua aktivitas pengembangan pada dasarnya adalah tindakan menciptakan boundary
- Ironisnya: kita membuat boundary untuk menangani kompleksitas, tetapi boundary itu sendiri menjadi sumber kompleksitas baru
Boundary yang muncul dalam kode
- Boundary pemanggil-yang dipanggil: ambiguitas kontrak seperti mengembalikan null vs melempar exception
- Boundary interface: hukum abstraction leakage - kompleksitas yang disembunyikan pada akhirnya akan menembus boundary
- Boundary dependency: API dan library eksternal bisa berubah tanpa peringatan
- Boundary transformasi: seperti object-relational impedance mismatch, setiap kali melintasi boundary terjadi distorsi atau kehilangan informasi
- Boundary kepercayaan: batas antara data tervalidasi vs data yang belum tervalidasi → kerentanan keamanan seperti menerima webhook tanpa signature
- Boundary desain-implementasi: requirement → desain → implementasi → operasi, di setiap tahap akumulasi kehilangan informasi terus terjadi
Boundary fisik
- Boundary urutan: state dapat berubah di antara titik-titik asinkron, dan ini makin serius dalam sistem terdistribusi
- Boundary skala: ketika melewati titik kritis, yang terjadi bukan lagi perubahan kuantitatif melainkan perubahan kualitatif
- Boundary lingkungan: memunculkan situasi seperti "berjalan baik di komputer saya"
- Boundary infrastruktur: saat layanan dipisahkan, atomicity tidak bisa dijamin
Boundary yang muncul antar-manusia
- Boundary organisasi: Conway's Law - struktur organisasi menentukan struktur sistem. Saat tim direstrukturisasi, boundary kode dan boundary organisasi bisa tidak lagi selaras
- Boundary komunikasi: seperti permainan pesan berantai, niat berubah setiap kali requirement diteruskan, sementara tacit knowledge bahkan tidak ikut tersampaikan
- Boundary pengguna-pengembang: boundary yang dibuat pengembang demi keamanan bisa terasa sebagai hambatan yang merepotkan bagi pengguna
Cara mengelola boundary
- Sadari boundary yang tersembunyi: perhatikan coupling yang tidak terlihat di kode, seperti dua layanan yang berbagi tabel DB yang sama
- Pattern bukan jawaban: pattern hanyalah "solusi yang efektif dalam kondisi tertentu", jadi jangan diterapkan secara membabi buta
- Tiga pertanyaan yang harus diajukan di depan boundary:
- Apa yang melintasi boundary ini?
- Apa yang terjadi jika boundary ini rusak?
- Siapa yang mengelola boundary ini?
- Tidak menarik boundary juga merupakan pilihan: mempertahankan monolith, menahan diri dari pemisahan yang tergesa-gesa, dan sebagainya
- Boundary berevolusi: dipisahkan lalu digabungkan, digabungkan lalu dipecah lagi secara berulang → perlu ditinjau ulang secara sadar dan berkala
Belum ada komentar.