Event Sourcing

Event Sourcing
Pada pattern ini semua event yg terjadi itu dicapture dalam object dan kemudian disimpan sebagai log. Log ini berfungsi untuk proses auditing atau dapat digunakan untuk mengembalikan state dari aplikasi ke kondisi semula. Agar dapat membangun semuanya dari kondisi nol dari log maka sequecen nya harus dipertahankan.
Kegunaan log yg lain adalah untuk memperbaiki kesalahan yg dilakukan pada masa lalu. Klo di dunia accounting dinamakan dengan reversal adjustment atau retroactive change.

Jadi pada suatu aplikasi kita memiliki dua data untuk di kelola. Salah satu nya adalah application state. Data yg satu ini pasti ada di setiap aplikasi apapun. Application state ini menggambarkan keadaan aplikasi yg terkini atau current state. Yang kedua adalah event log. Event log menyimpan perubahan2 state yg terjadi pada aplikasi tersebut.

Kita dapat memperoleh beberapa keuntungan dengan menyimpan log dari event. Diantaranya adalah :

1. Kita dapat membangun lagi dari nol state pada system yg baru berjalan dari event log ke state terakhirnya. Complete Rebuild
2. Kita dapat mengetahui state dari aplikasi pada suatu saat yg kita inginkan bukan hanya state skarang saja
3. Even Replay. Kita dapat memperbaiki event yg salah pada masa silam. Kita dapat menggantinya dan kita dapat melakukan analisa dengan mengubah event nya.

Contoh yg paling nyata dari EventSourcing ini adalah Version Control System.

Dengan menyimpan event log maka sebenarny kita tidak memerlukan lagi application state. Karena kita dapat membangunnya dari Log. Tetapi jika lognya sudah terlalu banyak maka akan memakan waktu lama untuk membangunnya. Dan jika application state lebih sering diquery maka kita lebih baik menyimpan keduanya. Application state dapat di simpan di memory atau di database. Event log disimpan pada data store.

Jika kita ingin membangun application state dari awal maka yg harus kita lakukan adalah mengambil semua lognya dan mengeksekusinya satu persatu secara berurutan dan hasil akhirnya adalah state terakhir. Jika log nya sangat banyak maka hal ini menjadi permasalahan dan akan menurunkan performance. Kita dapat menggunakan teknik yg dinamakan snapshot. Jadi pada satu saat kita akan melakukan snapshot terhadap application state. Jadi state aplikasi tersebut disimpan. Kemudian ketika aplikasi mati atau down atau crash. Kita hanya perlu mengulangi event mulai dari snapshot tersebut dan tidak perlu mengeksekusi keseluruhan dari event. Snapshot ini dapat dilakukan secara parallel jadi kita tidak perlu mematikan applikasi

Event Handler Logic

Untuk menangani event yg terjadi kita dapat menggunakan Domain Model atau transaction script. Transaction Script merupakan cara yg paling sering digunakan dalam hal ini. Tetapi hanya sebatas pemilihan logic. Pemrosesannya tetap dilakukan oleh domain model. Jadi ada 2 responsibility yg terpisah. Yang pertama adalah processing domain logic dan yg kedua adalah processing selection logic.
Processing selection logic dapat dilakukan pada event object tersebut atau memiliki object terpisah yaitu event processor object.

Jika kita tidak melakukan reversal maka kita tidak perlu menyimpan log event pada domain.
Hal2 yg dapat di simpan pada event dapat berupa nilai sebelumnya dari state domain yg berubah, meyimpan perubahannya atau bahkan delta perubahannya. Yg lain nya adalah hasil perhitungan yg dilakukan oleh domain model.

Ada dua cara yg dapat dilakukan pada proses reversal. Kita dapat mengulangi semua event dari snapshot terakhir dan mengubah event pada timing yg diinginkan. Atau kita juga dapat dengan mereverse kejadian atau mundur ke belakang. Sehingga kita harus memiliki log dari event tersebut di dalam domain dan kita juga dapat menyerahakn proses reversal tersebut pada event dan melakukan double dispatch pattern. Yang paling penting untuk diingat adalah kita harus menyimpan nilai sebelum dari suatu object pada event yg bersangkutan.

Proses Event Replay yg digunakan untuk mengembalikan state aplikasi ke posisi terakhir haruslha memperhatikan interaksi dengan system lain. Karena jika system lain menerima event terhadap message dikirim, system tersebut tidak dapat membedakan apakah hal ini merupakan event replay atau transaksi yg sebenarnya. Sehingga kita harus membuat gateway untuk berhubungan dengan external system. External gateway ini akan dinonaktifkan jjika kita sengan melakukan proses replay. Jadi domain logic harus dapat membedakan proses replay dan tidak.

Dan event replay menjadi lebih pelik jika kita membutuhkan informasi dari external system. Karena data yg dibutuhkan dari external system tersebut merupakan data yg ada pada masa silam. Sehingga kita dapat mengcache query ke external sitem pada Gateway. Atau kita meminta data yg lama tersebut secara explicit ke external system.

Cara yg mudah untuk menyimpan event log adalah menserialize event tersebut dan menyimpannya sebagai audit log. Salah satu penggunaan event sourcing ini yg lain adalah melakukan trace terhadap apa2 saja yg dilakukan oleh user pada screen aplikasi. Sehingga kita dapat mengetahui kesalahan pengguanaan atau malfunction dll.

Dengan menggunakan event sourcing yang memiliki arah Event-Driven Architecture ini kita dapat mencapai scalability. Kita akan memiliki aplikasi yg loose couple. Kita juga dapat membuat system yg terkluster dengan in memory database. Dan menjaga agar object-object tersebut menjadi up to date melalui series of event.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: