Sumber peristiwa ( sumber peristiwa, pencatatan peristiwa, pembuatan peristiwa) adalah pola arsitektur yang kuat di mana semua perubahan yang dibuat pada status aplikasi disimpan sesuai urutan terjadinya. Catatan ini berfungsi baik sebagai sumber untuk mendapatkan status saat ini dan sebagai jejak audit dari apa yang telah terjadi dalam aplikasi selama masa pakainya. Sumber acara memfasilitasi perubahan dan pembacaan data yang terdesentralisasi. Arsitektur ini berskala dengan baik dan cocok untuk sistem yang sudah bekerja dengan penanganan acara atau ingin bermigrasi ke arsitektur semacam itu.
Apa itu Sumber Acara
Pakar domain biasanya mendeskripsikan sistem mereka sebagai kumpulan entitas , yang merupakan wadah untuk menyimpan keadaan dan peristiwa yang mencerminkan perubahan entitas sebagai hasil dari pengolahan data masukan dalam berbagai proses bisnis. Peristiwa sering kali dipicu oleh perintah yang datang dari pengguna, proses latar belakang, atau integrasi dengan sistem eksternal.
Pada dasarnya, Sumber acara berfokus pada acara yang terkait dengan perubahan dalam sistem.
Banyak pola arsitektur melihat entitas sebagai konsep utama. Template ini menjelaskan cara menyimpannya, cara mengaksesnya, dan cara memodifikasinya. Dalam gaya arsitektur ini, peristiwa sering kali "menyamping": itu adalah konsekuensi dari entitas yang berubah.
Biasanya, arsitektur ini didasarkan pada penyimpanan entitas seperti database relasional atau penyimpanan dokumen. Meskipun peristiwa mungkin hadir dalam arsitektur seperti itu, pada intinya peristiwa tersebut bukanlah konsep utama, dan dapat dipisahkan dari entitas yang terkait dengannya, serta tersembunyi di balik lapisan logika bisnis.
Peristiwa Sourcing membalikkan pendekatan ini dengan berfokus pada implementasi peristiwa: bagaimana mereka bertahan dan bagaimana mereka dapat digunakan untuk mendapatkan keadaan suatu entitas. Dalam kasus ini, database akan berisi log sekuensial dari semua peristiwa yang terjadi selama masa pakai sistem.
Di bawah ini adalah perbandingan Event Store dengan Entity Store (dijelaskan lebih detail di bawah):
Event sourcing, menggunakan event sebagai konsep arsitektur utama, juga merupakan paradigma pemodelan domain yang lebih mencerminkan pandangan pelanggan terhadap sistem. Merancang sistem dengan penekanan pada peristiwa dan log peristiwa memberikan manfaat berikut:
- , « » .
- (command/query responsibility), .
- , , , .
Event Sourcing
Mari kita lihat contoh sederhana dengan rekening bank. Kami akan memiliki entitas yang mewakili Rekening Bank. Untuk mempermudah, kami hanya akan membuat satu akun tanpa mengidentifikasinya menggunakan nomor akun atau dengan cara lain. Akun tersebut akan menjaga saldo dana saat ini.
Dua perintah (perintah) akan tersedia untuk akun : deposit uang (deposit) dan penarikan uang (penarikan). Perintah tersebut akan menunjukkan jumlah yang akan disimpan atau ditarik. Kami juga akan menetapkan aturan bisnis yang memverifikasi bahwa perintah penarikan hanya dapat diproses jika jumlah yang diminta sama dengan atau kurang dari saldo akun saat ini.
Dengan pendekatan ini, dua peristiwa dapat dibedakan (peristiwa)- "Akun Dikreditkan" dan "Akun Didebit". Peristiwa ini berisi informasi tentang jumlah yang telah disimpan atau ditarik. Ini dapat disederhanakan menjadi satu peristiwa dengan jumlah positif atau negatif, tetapi dalam contoh ini kita akan membaginya.
Diagram di bawah menunjukkan model data.
Perhatikan bahwa peristiwa adalah "bentuk lampau". Mereka menunjukkan apa yang terjadi di sistem pada saat mereka ditulis, dan disimpan hanya jika perintah berhasil diproses. Dengan pendekatan ini, perhatian harus diberikan untuk tidak membingungkan perintah dengan kejadian. Apalagi jika mereka saling mencerminkan.
Urutan perintah mungkin terlihat seperti ini:
1. deposit {jumlah: 100} - deposit 100
2. penarikan {jumlah: 80} - penarikan 80
3. penarikan {jumlah: 50} - penarikan 50
Implementasi paling sederhana dari Event Sourcing membutuhkan log peristiwa , yang hanya merupakan urutan peristiwa. Saat memproses perintah di atas, Anda mendapatkan log seperti itu.
Perintah ketiga tidak dapat dijalankan karena jumlah yang diminta melebihi saldo yang tersedia.
Untuk mendapatkan keseimbangan saat ini, sistem harus memproses atau "menghasilkan" peristiwa dalam urutan kemunculannya. Untuk contoh kami, mungkin terlihat seperti ini:
- rekening bank {saldo saat ini: 0} (keadaan awal)
rekening bank {saldo saat ini: 0} (keadaan awal) - bank account { current balance: 100 } (processed: Account Credited, +100)
{ : 100 } (: , +100) - bank account { current balance: 20 } (processed: Account Debited, -80)
{ : 20 } (: , -80)
Saldo saat ini dihitung melalui pemrosesan semua peristiwa hingga saat ini. Karena setiap peristiwa memiliki stempel waktu implisit, status akun dapat dihitung kapan saja dengan memproses semua peristiwa untuk jangka waktu yang diperlukan.
Ini adalah contoh lengkap (meskipun sepele) dari Sumber Acara. Dalam sistem nyata, contoh ini kemungkinan besar perlu diperpanjang.
Mungkin perlu untuk menyimpan urutan perintah agar dapat mengidentifikasi bagaimana peristiwa itu terjadi, serta membuat log peristiwa kesalahan terpisah untuk merekam perintah yang gagal diselesaikan untuk penanganan kesalahan lebih lanjut dan memelihara riwayat lengkap keberhasilan dan tim yang tidak berhasil.
Seiring waktu, seiring bertambahnya jumlah perintah, saldo akun saat ini mungkin perlu dipertahankan sehingga ketika perintah penarikan diterima, tidak perlu memproses daftar lengkap peristiwa untuk menentukan apakah perintah dapat dijalankan (mis., Jika akun memiliki cukup dana). Ini adalah contoh penyimpanan turunan dan pada dasarnya sama dengan penyimpanan entitas.
Di bawah ini adalah bagaimana penyimpanan entitas akan mencari contoh kita setelah memproses semua perintah.
Jelas, dibandingkan dengan Toko Acara yang lengkap, ini adalah contoh yang sangat primitif. Dan inilah salah satu alasan mengapa banyak pengembang hanya menggunakan penyimpanan entitas. Dalam hal ini, saldo akun saat ini tersedia segera dan tidak perlu memproses semua peristiwa sejarah.
Namun, Sumber Peristiwa tidak mengecualikan penyimpanan entitas. Seringkali, toko entitas hadir dalam proyek Sumber Acara juga.
Akhir dari bagian pertama.
