Saya sangat menyukai konsep-konsep dalam video The Principles of Clean Architecture oleh Paman Bob Martin . Tetapi saya merasa bahwa pola ini seperti kombinasi dari pola Abstrak Pabrik dan Pembangun pada intinya.
Ini adalah salah satu cara untuk menulis program yang bagus tetapi bukan satu-satunya cara.
Rel dan reaksi adalah 2 kerangka kerja yang muncul di pikiran yang tidak mempromosikan arsitektur bersih semacam ini. Rails mengharapkan logika bisnis Anda ada di model ( FatModels dan SkinnyControllers ), dan bereaksi di dalam komponen Anda. Keduanya mendekati secara ketat logika bisnis dan kode kerangka kerja .
Saya tidak menemukan kesalahan dalam salah satu dari 3 cara ini. Itu adalah panggilan penilaian untuk memilih siapa pun.
Tetapi dalam video saya merasa dia menyarankan bahwa arsitektur yang bersih harus memiliki batas yang jelas antara logika bisnis dan kerangka kerja. Kerangka kerja (web, android, dll.) Harus berupa plugin yang terhubung ke logika bisnis. Dia bahkan secara halus mengejek rel dalam video.
Jadi, Apakah "Arsitektur Bersih" oleh Bob Martin aturan praktis untuk semua arsitektur atau hanya salah satu pilihan?
sumber
Jawaban:
Sementara "Arsitektur Bersih" baik-baik saja dan memiliki banyak keuntungan, penting untuk diingat bahwa:
Arsitektur Bersih sebagian besar adalah re-branding Robert C. Martin dan evolusi pendekatan terkait seperti Arsitektur Bawang oleh Jeffrey Palermo (2008) dan Arsitektur Heksagonal ("Pelabuhan dan Adaptor") oleh Alistair Cockburn dan lainnya (<2008).
Masalah yang berbeda memiliki persyaratan yang berbeda pula. Arsitektur Bersih dan pendekatan terkait mengubah decoupling, fleksibilitas, dan inversi ketergantungan hingga sebelas, tetapi mengorbankan kesederhanaan. Ini tidak selalu bagus.
Prekursor untuk arsitektur ini adalah pola MVC klasik dari Smalltalk. Ini menguraikan model dari antarmuka pengguna (pengontrol dan tampilan), sehingga model tidak bergantung pada UI. Ada banyak variasi MVC seperti MVP, MVVM, ....
Sistem yang lebih kompleks tidak hanya memiliki satu antarmuka pengguna, tetapi mungkin beberapa antarmuka pengguna. Banyak aplikasi memilih untuk menawarkan API REST yang dapat dikonsumsi oleh UI apa pun, seperti aplikasi web atau aplikasi seluler. Ini mengisolasi logika bisnis di server dari UI ini, sehingga server tidak peduli aplikasi apa yang mengaksesnya.
Biasanya, server masih bergantung pada layanan backend seperti database atau penyedia pihak ketiga. Ini sangat bagus, dan mengarah ke arsitektur berlapis sederhana.
Arsitektur Hexagonal melangkah lebih jauh dan berhenti membuat perbedaan antara frontend dan backend. Setiap sistem eksternal dapat berupa input (sumber data) atau output. Sistem inti kami mendefinisikan antarmuka (port) yang diperlukan, dan kami membuat adaptor untuk sistem eksternal apa pun.
Salah satu pendekatan klasik untuk decoupling yang kuat adalah arsitektur berorientasi layanan (SOA), di mana semua layanan mempublikasikan acara ke dan mengkonsumsi acara dari bus pesan bersama. Pendekatan serupa kemudian dipopulerkan oleh layanan mikro.
Semua pendekatan ini memiliki kelebihan , seperti membuatnya lebih mudah untuk menguji sistem secara terpisah (dengan mengganti semua sistem eksternal yang berinteraksi dengan implementasi tiruan). Mereka membuatnya lebih mudah untuk menyediakan beberapa implementasi untuk satu jenis layanan (misalnya menambahkan prosesor pembayaran kedua), atau untuk menukar implementasi layanan (mis. Pindah dari database Oracle ke PostgreSQL, atau dengan menulis ulang layanan Python di Go) .
Tetapi arsitektur ini adalah Ferrari arsitektur: mahal, dan kebanyakan orang tidak membutuhkannya. Fleksibilitas tambahan dari Arsitektur Bersih dll. Datang dengan biaya kompleksitas yang lebih tinggi. Banyak aplikasi dan terutama aplikasi web CRUD tidak mendapat manfaat dari itu. Masuk akal untuk mengisolasi hal-hal yang mungkin berubah, misalnya dengan menggunakan templat untuk menghasilkan HTML. Lebih tidak masuk akal untuk mengisolasi hal-hal yang tidak mungkin berubah, misalnya database pendukung. Apa yang mungkin berubah tergantung pada konteks dan kebutuhan bisnis.
Kerangka kerja membuat asumsi tentang apa yang akan berubah. Misalnya Bereaksi cenderung menganggap bahwa desain dan perilaku komponen berubah bersama-sama, jadi tidak masuk akal untuk memisahkannya. Beberapa kerangka kerja menganggap bahwa Anda mungkin ingin mengubah kerangka kerja. Dengan demikian, kerangka kerja menghadirkan sejumlah penguncian. Misalnya ketergantungan Rail pada pola Rekaman Aktif (sangat keras!) Membuatnya sulit untuk mengubah strategi akses data Anda menjadi pola Repositori (sering lebih unggul). Jika harapan Anda terhadap perubahan tidak sesuai dengan kerangka kerja, menggunakan kerangka kerja yang berbeda mungkin lebih baik. Banyak kerangka kerja web lainnya tidak membuat asumsi tentang akses data.
sumber
Bahkan tidak dekat.
Ketika Anda melihat ini:
Anda sedang melihat desain grafik objek. Ini menentukan apa yang tahu tentang apa. Apa yang hilang dari cerita ini adalah bagaimana grafik objek itu dibangun. Maaf, tetapi Anda tidak akan menemukannya di sini. Tidak ada penyebutan konstruksi.
Anda dapat membangun semua ini tanpa pabrik dan pembangun abstrak. Saya tahu karena saya sudah melakukannya . Saya bahkan tidak berangkat untuk menghindarinya. Aku mencintai mereka. Aku hanya tidak membutuhkannya. Saya hanya menggunakan referensi lewat. Ketergantungan Injeksi adalah istilah mewah untuk itu.
Sebenarnya, saya bisa membangun semua yang Anda lihat dalam diagram itu di main. Kemudian panggil satu metode pada satu objek untuk memulai semuanya.
Sekarang segala sesuatunya harus ada sebelum Anda bisa mendorongnya ke hal lain. Saya menjelajahinya di sini dan memberikan diagram kecil yang lucu ini:
Dan Anda dapat membangun semua itu tanpa meninggalkan
main().Saya akan merekomendasikan menggunakan pembangun dan pabrik ketika Anda ingin memecah tumpukan kode konstruksi prosedural menjadi potongan konseptual berukuran bagus menggigit. Tetapi tidak ada apa pun dalam arsitektur bersih atau arsitektur kata kunci lainnya yang menuntut Anda melakukannya. Jadi, jika Anda ingin bertahan
main(), baiklah. Tolong, kasihanilah .Saya menganggap Arsitektur Bersih sebagai kata kunci yang digunakan untuk mengarahkan orang ke blog dan buku. Blog dan buku itu memiliki penjelasan yang sangat bagus tentang Arsitektur tua yang sangat mirip dengan nama lama yang digunakan untuk mengarahkan orang ke blog yang lebih tua dan buku yang lebih tua. Secara khusus Bawang serta Port dan Adaptor. Tidak ada satu-satunya pilihan arsitektur yang Anda miliki.
Saya suka Paman Bob karena dia adalah pembicara dan penulis publik yang luar biasa. Dia membuatku memikirkan hal-hal yang tidak akan kumiliki. Tetapi jika Anda membiarkan hal itu mengubah Anda menjadi seorang fanatik agama yang bersikeras bahwa segala sesuatu harus dilakukan dengan caranya sendiri, Anda akan segera menemukan bahwa memperbarui dokumentasi adalah yang paling dekat, saya akan membiarkan Anda membuka kode saya.
Arsitektur kata kunci berguna ketika Anda memiliki kode hidup lama yang perlu bertahan saat dunia berubah di sekitarnya. Saat itulah ia bersinar. Jika dunia stabil dibandingkan dengan kode, maka Anda membuat sesuatu menjadi mewah tanpa alasan yang bagus.
Tidak peduli seberapa hebat sesuatu yang tampak ada konteks yang Anda bisa masukkan itu akan membuatnya masuk akal Maaf, ini bukan peluru perak juga.
Kamu benar. Dia melakukannya. Paman Bob merasa bahwa kerangka kerja dapat diperlakukan seperti perpustakaan. Dan mereka bisa. Tetapi bahkan keputusan itu harus Anda bayar.
Apa yang ingin dilestarikan oleh Tn. Martin adalah ruang di mana bahasa tujuan umum Anda masih bersifat umum. Anda menyerah ketika Anda menyebarkan kerangka kerja di mana-mana. Ketika Anda melakukan itu, Anda sedang menuju ke jalur morphing bahasa Anda menjadi sesuatu yang disebut bahasa spesifik domain. HTML adalah bahasa khusus domain. Itu melakukan pekerjaannya dengan sangat baik tetapi ada pekerjaan lain yang tidak bisa dilakukan sama sekali.
Selama kebutuhan Anda diantisipasi oleh kerangka kerja, segalanya akan berjalan sangat lancar. Sangat menyenangkan untuk mengantisipasi kebutuhan Anda. Ini menempatkan Anda dalam sebuah kotak yang membuat hal-hal sederhana. Hanya mengerti apa yang Anda menyerah untuk mendapatkan ini. Jika Anda menyebarkan Spring di mana-mana Anda tidak dapat mengiklankannya sebagai pekerjaan Java lagi. Ini pekerjaan Java / Spring. Saya bisa mengatakan hal yang sama tentang Ruby dan Rails tetapi Rails sudah lama makan siang Ruby.
sumber
Mengutip video:
diikuti oleh:
Arsitekturnya, seperti gabungan surat, hanyalah satu opsi di antara banyak.
Apa yang tidak opsional adalah masalah yang coba dipecahkan oleh arsitektur.
Jika Anda memahami masalah apa yang disebabkan oleh gabungan surat SQL vs solusi lain, maka pilihan arsitektur Anda akan diinformasikan dan bahkan jika Anda terpaksa memilih solusi 'buruk', Anda akan mengetahui dan mengurangi kekurangan mereka.
Jika Anda mengikuti gaya arsitektur hanya karena itu dipikirkan dengan baik, maka Anda cenderung membuat kesalahan dan menghadapi masalah yang sama.
sumber
"Arsitektur Bersih" jelas "hanya" salah satu opsi. Saya berpendapat itu adalah salah satu pilihan buruk untuk sebagian besar proyek, terutama untuk proyek berorientasi objek.
Berikut ini adalah analisis kalimat-demi-kalimat dari artikel Paman Bob tentang Arsitektur Bersih dengan alasan pernyataan di atas:
Arsitektur Bersih dari perspektif Berorientasi Objek
sumber
Arsitektur Bersih adalah seperangkat prinsip dan pola untuk mengatasi sejumlah gejala umum yang sering dihadapi organisasi pengembangan perangkat lunak sepanjang masa membangun aplikasi yang kompleks. Tn. Martin berusaha keras dalam buku ini untuk mengidentifikasi gejala dan akar penyebab berdasarkan pengalamannya yang luas di lapangan, dan untuk memperjelas peran arsitektur dalam mengurangi masalah ini.
Namun, Ini bukan Aturan Jempol, atau obat mujarab untuk semua penyakit. Jika Anda membaca buku ini, Anda akan memiliki pemahaman yang lebih baik tentang jika / kapan / bagaimana menerapkan prinsip-prinsip dan pola-pola yang ia anjurkan (dan pertukaran yang terlibat). Jika Anda belum membaca buku ini, Anda kemungkinan akan membuat asumsi, aplikasi, penilaian, dan pernyataan yang salah berdasarkan informasi yang tidak lengkap.
sumber