Bacalah bagian pertama.
Fitur implementasi Event Sourcing
Dari sudut pandang teknis, Event Sourcing hanya membutuhkan implementasi event logging dan membaca dari log.
Dalam kasus yang paling sederhana, file dapat digunakan sebagai penyimpanan acara, di mana acara terpisah direkam pada setiap baris, atau beberapa file, ketika setiap acara disimpan ke file terpisah. Tetapi sebagai aturan, dalam sistem besar yang menuntut paralelisme dan skalabilitas, metode penyimpanan yang lebih andal digunakan.
Log peristiwa adalah pola yang sangat umum digunakan bersama dengan Makelar pesan (middleware berorientasi pesan) dan sistem pemrosesan aliran peristiwa. Makelar pesan, yang digunakan sebagai log peristiwa, dapat menyimpan seluruh riwayat pesan jika diperlukan.
Model relasional dan dokumenter biasanya berfokus pada pemodelan entitas. Dalam model seperti itu, status saat ini mudah diperoleh dengan membaca satu atau lebih baris atau dokumen. Perlu dicatat bahwa Sumber Peristiwa dan model relasional tidak saling eksklusif. Sistem sumber acara sering kali menyertakan keduanya. Perbedaan utama dengan Sumber Peristiwa adalah penyimpanan entitas tidak lagi diperlakukan sebagai data mentah. Ini dapat diganti atau dibangun kembali melalui pemrosesan ulang log peristiwa.
Dalam sistem Sumber Peristiwa yang lebih kompleks, penyimpanan status turunan harus ada untuk permintaan baca yang efisien, karena mengambil status saat ini melalui pemrosesan seluruh log peristiwa dari waktu ke waktu dapat menghentikan penskalaan. Baik database relasional maupun dokumen dapat digunakan sebagai log peristiwa dan sebagai repositori entitas turunan, yang melaluinya Anda dapat dengan cepat mendapatkan status saat ini. Faktanya, pemisahan perhatian ini adalah CQRS (Command Query Responsibility Segregation). Semua permintaan diarahkan ke penyimpanan turunan sehingga dapat dioptimalkan secara independen dari operasi tulis.
Selain teknis, ada hal lain yang perlu diperhatikan.
Potensi Masalah Sumber Acara
Terlepas dari kelebihan Event Sourcing, ini juga memiliki kekurangan.
Tantangan terbesar biasanya ada di pola pikir para pengembang. Pengembang harus melampaui aplikasi CRUD konvensional dan penyimpanan entitas. Acara sekarang harus menjadi konsep utama.
Dengan Sumber Acara, banyak upaya dihabiskan untuk acara pemodelan. Setelah peristiwa ditulis ke log, peristiwa tersebut harus dianggap tidak berubah, jika tidak, dan riwayat serta status dapat rusak atau rusak. Log peristiwa adalah data mentah, yang berarti Anda harus sangat berhati-hati untuk memastikan bahwa log itu berisi semua informasi yang diperlukan untuk mendapatkan status lengkap sistem pada titik waktu tertentu. Juga harus diingat bahwa peristiwa dapat ditafsirkan ulang sebagai sistem (dan bisnis yang diwakilinya) berubah seiring waktu. Dan jangan lupa tentang kejadian yang salah dan mencurigakan dengan pemrosesan validasi data yang benar.
Untuk model domain sederhana, perubahan cara berpikir ini bisa sangat mudah, tetapi untuk model domain yang lebih kompleks bisa menjadi masalah (terutama dengan banyak ketergantungan dan hubungan antar entitas). Mungkin sulit untuk mengintegrasikan dengan sistem eksternal yang tidak menyediakan data pada titik waktu tertentu.
Sumber peristiwa dapat berfungsi dengan baik pada sistem besar karena pola log peristiwa secara alami diskalakan secara horizontal. Misalnya, log peristiwa dari satu entitas tidak harus secara fisik berada dengan log peristiwa entitas lain. Namun, kemudahan penskalaan ini menyebabkan masalah tambahan dalam bentuk pemrosesan asinkron dan akhirnya data yang konsisten. Perintah untuk mengubah status dapat datang ke node mana pun, setelah itu sistem perlu menentukan node mana yang bertanggung jawab atas entitas yang sesuai dan mengirim perintah ke node ini, kemudian memproses perintah, dan kemudian mereplikasi acara yang dihasilkan ke node lain tempat log peristiwa disimpan. Dan hanya setelah proses ini selesai, acara baru menjadi tersedia sebagai bagian dari status sistem.Jadi, Event Sourcing sebenarnya membutuhkan pemrosesan perintah agar terpisah dari permintaan status, yaitu CQRS.
Oleh karena itu, sistem Sumber Peristiwa perlu memperhitungkan interval waktu antara mengeluarkan perintah dan menerima pemberitahuan tentang pencatatan peristiwa yang berhasil. Status sistem yang dilihat pengguna saat ini mungkin "salah". Atau lebih tepatnya, agak ketinggalan jaman. Untuk mengurangi pengaruh faktor ini, perlu diperhitungkan saat merancang antarmuka pengguna dan komponen lainnya. Juga diperlukan untuk menangani situasi dengan benar ketika sebuah perintah gagal, dibatalkan selama eksekusi, atau satu peristiwa diganti dengan yang lebih baru ketika data diperbarui.
Masalah lain akan muncul ketika peristiwa terakumulasi dari waktu ke waktu dan akan perlu untuk bekerja dengannya. Menuliskannya setelah diproses adalah satu hal, mengerjakan seluruh histori adalah hal lain. Tanpa fungsi ini, log peristiwa akan kehilangan nilainya sepenuhnya. Hal ini terutama berlaku untuk pemulihan bencana atau saat memigrasi penyimpanan turunan, saat semua peristiwa mungkin perlu diproses ulang untuk memperbarui data. Untuk sistem dengan banyak kejadian, memproses ulang seluruh log dapat melebihi waktu pemulihan yang diizinkan. Jepretan berkala sistem dapat membantu di sini sehingga Anda dapat mulai memulihkan dari kondisi sehat selanjutnya.
Juga perlu mempertimbangkan struktur acara. Struktur acara dapat berubah seiring waktu. Kumpulan bidang dapat berubah. Mungkin ada situasi di mana peristiwa lama perlu diproses oleh logika bisnis saat ini. Dan kehadiran skema acara yang dapat diperluas akan membantu di masa depan, jika perlu, membedakan acara baru dari yang lama. Snapshot periodik juga membantu mengisolasi perubahan besar dalam struktur peristiwa.
kesimpulan
Event Sourcing adalah pendekatan yang ampuh dengan manfaat. Salah satunya adalah mempermudah perluasan sistem di masa mendatang. Karena log peristiwa menyimpan semua peristiwa, mereka dapat digunakan di sistem eksternal. Ini cukup mudah untuk diintegrasikan dengan menambahkan penangan acara baru.
Namun, seperti halnya keputusan arsitektur besar lainnya, Anda harus berhati-hati untuk memastikannya sesuai dengan situasi Anda. Batasan yang terkait dengan kompleksitas domain, persyaratan untuk konsistensi dan ketersediaan data, serta peningkatan volume data yang disimpan dan skalabilitas dalam jangka panjang, semua ini harus dipertimbangkan (dan ini sama sekali bukan daftar yang lengkap). Sama pentingnya untuk memperhatikan pengembang yang akan mengembangkan dan memelihara sistem seperti itu sepanjang siklus hidupnya.
Dan terakhir, jangan lupakan prinsip terpenting dari rekayasa perangkat lunak - berusahalah untuk membuat semuanya sesederhana mungkin (prinsip KISS).
