Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Beradaptasi dengan perubahan
Sistem perangkat lunak cenderung menjadi rumit. Salah satu alasan untuk ini bisa sering perubahan pada kebutuhan bisnis dan sedikit waktu untuk menyesuaikan arsitektur perangkat lunak yang sesuai. Alasan lain bisa menjadi investasi yang tidak memadai untuk menyiapkan arsitektur perangkat lunak pada awal proyek untuk beradaptasi dengan perubahan yang sering. Apapun alasannya, sistem perangkat lunak bisa menjadi rumit sampai pada titik di mana hampir tidak mungkin untuk melakukan perubahan. Oleh karena itu, penting untuk membangun arsitektur perangkat lunak yang dapat dipelihara sejak awal proyek. Arsitektur perangkat lunak yang baik dapat beradaptasi dengan perubahan dengan mudah.
Bagian ini menjelaskan cara merancang aplikasi yang dapat dipelihara dengan menggunakan arsitektur heksagonal yang mudah beradaptasi dengan kebutuhan non-fungsional atau bisnis.
Beradaptasi dengan persyaratan non-fungsional baru dengan menggunakan port dan adaptor
Sebagai inti dari aplikasi, model domain mendefinisikan tindakan yang diperlukan dari dunia luar untuk memenuhi persyaratan bisnis. Tindakan ini didefinisikan melalui abstraksi, yang disebut port. Port ini diimplementasikan oleh adaptor terpisah. Setiap adaptor bertanggung jawab atas interaksi dengan sistem lain. Misalnya, Anda mungkin memiliki satu adaptor untuk repositori database dan adaptor lain untuk berinteraksi dengan API pihak ketiga. Domain tidak menyadari implementasi adaptor, sehingga mudah untuk mengganti satu adaptor dengan yang lain. Misalnya, aplikasi mungkin beralih dari database SQL ke database NoSQL. Dalam hal ini, adaptor baru harus dikembangkan untuk mengimplementasikan port yang didefinisikan oleh model domain. Domain tidak memiliki dependensi pada repositori database dan menggunakan abstraksi untuk berinteraksi, sehingga tidak perlu mengubah apa pun dalam model domain. Oleh karena itu, arsitektur heksagonal menyesuaikan dengan persyaratan non-fungsional dengan mudah.
Beradaptasi dengan kebutuhan bisnis baru dengan menggunakan perintah dan penangan perintah
Dalam arsitektur berlapis klasik, domain tergantung pada lapisan persistensi. Jika Anda ingin mengubah domain, Anda juga harus mengubah layer persistensi. Sebagai perbandingan, dalam arsitektur heksagonal, domain tidak bergantung pada modul lain dalam perangkat lunak. Domain adalah inti dari aplikasi, dan semua modul lainnya (port dan adaptor) bergantung pada model domain. Domain menggunakan prinsip ketergantungan inversi untuk berkomunikasi dengan dunia luar melalui port. Manfaat dari ketergantungan inversi adalah bahwa Anda dapat mengubah model domain bebas tanpa takut untuk melanggar bagian lain dari kode. Karena model domain mencerminkan masalah bisnis yang Anda coba selesaikan, memperbarui model domain untuk beradaptasi dengan perubahan kebutuhan bisnis bukanlah masalah.
Ketika Anda mengembangkan perangkat lunak, pemisahan kekhawatiran adalah prinsip penting untuk diikuti. Untuk mencapai pemisahan ini, Anda dapat menggunakan pola perintah yang sedikit dimodifikasi. Ini adalah pola desain perilaku di mana semua informasi yang diperlukan untuk menyelesaikan operasi dienkapsulasi dalam objek perintah. Operasi ini kemudian diproses oleh penangan perintah. Penangan perintah adalah metode yang menerima perintah, mengubah keadaan domain, dan kemudian mengembalikan respons ke pemanggil. Anda dapat menggunakan klien yang berbeda, seperti API sinkron atau antrian asinkron, untuk menjalankan perintah. Kami menyarankan Anda menggunakan perintah dan penangan perintah untuk setiap operasi pada domain. Dengan mengikuti pendekatan ini, Anda dapat menambahkan fitur baru dengan memperkenalkan perintah baru dan penangan perintah, tanpa mengubah logika bisnis yang ada. Dengan demikian, menggunakan pola perintah membuatnya lebih mudah untuk beradaptasi dengan kebutuhan bisnis baru.
Decoupling komponen dengan menggunakan façade layanan atau pola CQRS
Dalam arsitektur heksagonal, adaptor utama bertanggung jawab untuk menggabungkan permintaan baca dan tulis yang masuk secara longgar dari klien ke domain. Ada dua cara untuk mencapai kopling longgar ini: dengan menggunakan pola layanan façade atau dengan menggunakan perintah permintaan tanggung jawab segregasi (CQRS) pola.
Pola layanan façade menyediakan antarmuka menghadap ke depan untuk melayani klien seperti lapisan presentasi atau microservice. Sebuah façade layanan menyediakan klien dengan beberapa operasi baca dan tulis. Ini bertanggung jawab untuk mentransfer permintaan masuk ke domain dan memetakan respons yang diterima dari domain ke klien. Menggunakan façade layanan mudah untuk layanan mikro yang memiliki tanggung jawab tunggal dengan beberapa operasi. Namun, ketika menggunakan façade layanan, lebih sulit untuk mengikuti tanggung jawab tunggal dan prinsip-prinsip terbuka. Prinsip tanggung jawab tunggal menyatakan bahwa setiap modul harus memiliki tanggung jawab atas hanya satu fungsi perangkat lunak. Prinsip terbuka-tertutup menyatakan bahwa kode harus terbuka untuk ekstensi dan ditutup untuk modifikasi. Ketika façade layanan meluas, semua operasi dikumpulkan dalam satu antarmuka, lebih banyak dependensi dienkapsulasi ke dalamnya, dan lebih banyak pengembang mulai memodifikasi façade yang sama. Oleh karena itu, kami sarankan menggunakan façade layanan hanya jika jelas bahwa layanan tidak akan memperpanjang banyak selama pengembangan.
Cara lain untuk menerapkan adaptor utama dalam arsitektur heksagonal adalah dengan menggunakan pola CQRS, yang memisahkan operasi baca dan tulis menggunakan kueri dan perintah. Seperti dijelaskan sebelumnya, perintah adalah objek yang berisi semua informasi yang diperlukan untuk mengubah keadaan domain. Perintah dilakukan dengan metode penangan perintah. Kueri, di sisi lain, tidak mengubah keadaan sistem. Satu-satunya tujuan mereka adalah mengembalikan data ke klien. Dalam pola CQRS, perintah dan kueri diimplementasikan dalam modul terpisah. Ini sangat menguntungkan untuk proyek yang mengikuti arsitektur berbasis peristiwa, karena perintah dapat diimplementasikan sebagai peristiwa yang diproses secara asinkron, sedangkan kueri dapat dijalankan secara sinkron dengan menggunakan API. Sebuah query juga dapat menggunakan database yang berbeda yang dioptimalkan untuk itu. Kerugian dari pola CQRS adalah bahwa dibutuhkan lebih banyak waktu untuk menerapkan daripada façade layanan. Kami merekomendasikan penggunaan pola CQRS untuk proyek-proyek yang Anda rencanakan untuk diskalakan dan dipelihara dalam jangka panjang. Perintah dan kueri menyediakan mekanisme yang efektif untuk menerapkan prinsip tanggung jawab tunggal dan mengembangkan perangkat lunak yang digabungkan secara longgar, terutama dalam proyek skala besar.
CQRS memiliki manfaat besar dalam jangka panjang, tetapi membutuhkan investasi awal. Oleh karenanya, kami menyarankan agar Anda mengevaluasi proyek Anda dengan hati-hati sebelum Anda memutuskan untuk menggunakan pola CQRs. Namun, Anda dapat menyusun aplikasi Anda dengan menggunakan perintah dan penangan perintah sejak awal tanpa memisahkan operasi baca/tulis. Ini akan membantu Anda dengan mudah refactor proyek Anda untuk CQRS jika Anda memutuskan untuk mengadopsi pendekatan itu nanti.
Penskalaan organisasi
Kombinasi arsitektur heksagonal, desain berbasis domain, dan (opsional) CQRS memungkinkan organisasi Anda untuk dengan cepat menskalakan produk Anda. Menurut Hukum Conway, arsitektur perangkat lunak cenderung berkembang untuk mencerminkan struktur komunikasi perusahaan. Pengamatan ini secara historis memiliki konotasi negatif, karena organisasi besar sering menyusun tim mereka berdasarkan keahlian teknis seperti database, bus layanan perusahaan, dan sebagainya. Masalah dengan pendekatan ini adalah bahwa pengembangan produk dan fitur selalu melibatkan masalah lintas sektor, seperti keamanan dan skalabilitas, yang memerlukan komunikasi konstan di antara tim. Penataan tim berdasarkan fitur teknis menciptakan silo yang tidak perlu dalam organisasi, yang mengakibatkan komunikasi yang buruk, kurangnya kepemilikan, dan kehilangan pandangan dari gambaran besar. Akhirnya, masalah organisasi ini tercermin dalam arsitektur perangkat lunak.
The Inverse Conway Manuver, di sisi lain, mendefinisikan struktur organisasi berdasarkan domain yang mempromosikan arsitektur perangkat lunak. Misalnya, tim lintas fungsi diberi tanggung jawab untuk serangkaian konteks terbatas tertentu, yang diidentifikasi dengan menggunakan DDD dan penyerbuan acara. Konteks yang dibatasi itu mungkin mencerminkan fitur produk yang sangat spesifik. Misalnya, tim akun mungkin bertanggung jawab atas konteks pembayaran. Setiap fitur baru ditugaskan ke tim baru yang memiliki tanggung jawab yang sangat kohesif dan longgar, sehingga mereka hanya dapat fokus pada pengiriman fitur itu dan mengurangi waktu ke pasar. Tim dapat diskalakan sesuai dengan kompleksitas fitur, sehingga fitur kompleks dapat diberikan kepada lebih banyak insinyur.
