Get best of the week

Mengapa Event Sourcing adalah antipattern untuk interaksi microservices

Halo lagi. Pada bulan Maret, OTUS meluncurkan aliran berikutnya dari kursus Arsitek Perangkat Lunak . Untuk mengantisipasi dimulainya kursus, kami telah menyiapkan terjemahan materi yang bermanfaat untuk Anda.



Baru-baru ini, arsitektur yang digerakkan oleh peristiwa (arsitektur yang digerakkan oleh peristiwa) dan, khususnya, Pengadaan Acara (generasi acara) telah menyebar luas. Ini didorong oleh keinginan untuk menciptakan sistem modular yang berkelanjutan dan dapat diskalakan. Dalam konteks ini, istilah "layanan mikro" sering digunakan. Menurut pendapat saya, layanan microser hanyalah salah satu cara untuk menerapkan " Konteks Terbatas ". Sangat penting untuk mendefinisikan dengan benar batasan-batasan modul, dan Desain Strategis , dijelaskan oleh Eric Evans dalam Domain Driven Design, membantu dalam hal ini . Ini membantu Anda mengidentifikasi / mendeteksi modul, batasan ("konteks terbatas") dan menjelaskan bagaimana konteks ini saling berhubungan satu sama lain (peta konteks, ContextMap).

Peristiwa domain sebagai dasar dari satu bahasa


Meskipun ini tidak secara eksplisit ditunjukkan dalam buku Eric Evans, peristiwa domain berkontribusi sangat baik untuk konsep DDD. Praktik seperti Event Storming Alberto Brandolini menggeser fokus acara dari teknis ke level organisasi dan bisnis. Di sini kita tidak berbicara tentang peristiwa antarmuka pengguna, seperti mengklik tombol (ButtonClickedEvent), tetapi tentang peristiwa domain yang merupakan bagian dari area subjek. Mereka dibicarakan dan dipahami oleh para ahli di bidang subjek. Acara-acara ini adalah konsep utama dan bantuan untuk membentuk satu bahasa ( bahasa mana-mana ), yang disetujui semua peserta (ahli materi pelajaran, pengembang, dll.).

Peristiwa domain digunakan untuk berkomunikasi antar konteks


Peristiwa domain dapat digunakan untuk berinteraksi antara konteks terbatas. Misalkan kita memiliki toko online dengan tiga konteks: Pesanan (pengiriman), Pengiriman (pengiriman), Faktur (akun).

Pertimbangkan acara "Pesanan Diterima" dalam konteks Pesanan. Konteks Faktur, serta konteks Pengiriman, tertarik melacak peristiwa ini, karena peristiwa ini memicu beberapa proses internal dalam konteks ini.

Mitos Konektivitas Lemah


Menggunakan peristiwa domain membantu mengembangkan modul yang digabungkan secara longgar. Modul individual mungkin tidak tersedia sementara. Tetapi untuk acara domain, sama sekali tidak penting apakah mereka tersedia atau tidak, karena acara tersebut hanya menggambarkan apa yang terjadi di masa lalu. Modul lain memutuskan kapan akan memproses acara. Anda mendapatkan sistem yang fleksibel secara default.

Selain pemisahan waktu, peristiwa domain memberi Anda keuntungan lain: konteks pesanan tidak perlu tahu bahwa konteks faktur dan pengiriman mendengarkan acara. Bahkan, dia bahkan tidak perlu tahu bahwa konteks ini ada.

Memang hebat, tetapi kesulitannya terletak pada memutuskan data apa yang akan disimpan dalam acara tersebut?

Jawaban sederhana: Sumber Acara!


Acara bermanfaat, jadi mengapa tidak menggunakannya secara maksimal. Ini adalah ide utama dari Event Sourcing . Anda menyimpan status unit tidak melalui memperbarui datanya (CRUD), tetapi melalui penggunaan aliran acara.
Selain fakta bahwa Anda dapat memainkan acara dan mendapatkan status, ada fitur lain dari Pengadaan Acara: Anda mendapatkan log audit lengkap secara gratis. Karena itu, ketika log seperti itu diperlukan, ketika memilih strategi penyimpanan, pastikan untuk memperhatikan Event Sourcing.

Pengadaan Acara hanyalah tingkat penyimpanan


Mungkin aneh bagi Anda bahwa saya segera beralih dari peristiwa domain ke penyimpanan, karena, jelas, ini adalah konsep dari berbagai tingkatan.

... dan inilah poin saya: Pengadaan Acara adalah solusi lokal yang digunakan hanya dalam satu konteks terbatas! Event Sourcing peristiwa tidak boleh ditarik keluar ke dunia luar! Konteks terbatas lainnya tidak perlu tahu tentang bagaimana data masing-masing disimpan, dan oleh karena itu tidak masalah jika beberapa konteks menggunakan Sumber Acara.

Jika Anda menggunakan Pengadaan Acara secara global, maka Anda mengungkapkan tingkat penyimpanan Anda.

Metode penyimpanan data menjadi API publik Anda. Setiap kali Anda membuat perubahan pada tingkat penyimpanan, Anda harus berurusan dengan perubahan di API publik.

Saya yakin semua orang akan setuju bahwa itu buruk ketika berbagai konteks terbatas berbagi data dalam database (relasional) karena konektivitas yang dihasilkan. Tetapi bagaimana ini berbeda dari Event Sourcing? Tidak ada. Tidak masalah jika Anda menggunakan acara bersama atau tabel bersama dalam database. Dalam kedua kasus, Anda membagikan detail penyimpanan.

Ada jalan keluar


Saya masih berpendapat bahwa peristiwa domain ideal untuk berinteraksi antara konteks terbatas, tetapi peristiwa ini tidak boleh terkait dengan peristiwa yang digunakan untuk Pengadaan Acara.

Solusi yang diajukan sangat sederhana: apa pun pendekatan yang Anda gunakan untuk menyimpan data (CRUD atau Peristiwa Acara), Anda menerbitkan acara domain di toko peristiwa global. Peristiwa ini mewakili API publik dari konteks Anda. Saat menggunakan Pengadaan Acara, Anda menyimpan acara Pengadaan Acara di toko lokal Anda, hanya dapat diakses untuk konteks terbatas ini.

kebebasan memilih


Memiliki acara domain terpisah di API publik memungkinkan Anda untuk memodelkannya secara fleksibel. Anda tidak terbatas pada model yang telah ditentukan oleh Pengadaan Acara.

Ada dua opsi untuk bekerja dengan "acara dunia nyata": Layanan Protokol Terbuka dan Bahasa Publik (Layanan Host Terbuka, Bahasa yang Diterbitkan) atau Pelanggan / Pemasok.

Layanan dengan protokol terbuka dan bahasa publik (Layanan Open Host, Bahasa yang Diterbitkan)


Hanya satu peristiwa domain yang diterbitkan yang berisi semua data yang diperlukan konteks terbatas lainnya. Dalam terminologi DDD, ini bisa disebut Layanan Open Host dan Bahasa yang Diterbitkan.



Awal kejadian dunia nyata "Pesanan Diterima" mengarah ke publikasi satu peristiwa domain yang diterima OrderAcc . Payload acara ini berisi semua data pesanan yang mungkin diperlukan konteks lain ... jadi semoga konteks Faktur dan Pengiriman dapat menemukan semua informasi yang mereka butuhkan.

Pelanggan / Pemasok


Untuk setiap konsumen, acara terpisah diterbitkan. Hal ini diperlukan untuk mengoordinasikan model setiap acara dengan hanya satu konsumen, tidak perlu menentukan model bersama yang umum. DDD menyebut hubungan ini Pelanggan / Pemasok.



Terjadinya peristiwa dunia nyata "Pesanan diterima" mengarah ke publikasi acara individu untuk masing-masing konsumen: InvoiceOrderAccepteddan DeliveryOrderAccepted. Setiap peristiwa domain hanya berisi data yang diperlukan untuk konteks penerima.

Saya tidak ingin membahas pro dan kontra dari pendekatan ini sekarang. Saya hanya ingin menarik perhatian pada fakta bahwa Anda dapat memilih jumlah acara domain dan data yang mereka simpan.

Ini adalah keuntungan yang Anda tidak boleh meremehkan, karena Anda dapat memutuskan bagaimana mengembangkan API dari konteks terbatas Anda tanpa terikat dengan acara Sumber Acara.

Kesimpulan


Mengekspos bagian penyimpanan adalah anti-pola yang terkenal. Berbicara tentang penyimpanan, kami terutama berpikir tentang tabel database, tetapi kami melihat bahwa peristiwa yang digunakan untuk Pengadaan Acara hanyalah cara lain untuk menyimpan data. Oleh karena itu, memberi mereka juga merupakan pola anti.


Terjemahan: "pengembang yang baik seperti manusia serigala takut akan peluru perak."

Event Sourcing adalah pendekatan yang kuat jika digunakan dengan benar (lokal). Pada pandangan pertama nampaknya untuk arsitektur yang berorientasi pada peristiwa ini adalah peluru perak, tetapi jika Anda melihat lebih dekat, Anda dapat melihat bahwa pendekatan ini dapat mengarah pada hubungan yang kuat ... yang tentu saja tidak Anda inginkan.

Referensi


Selain pengalaman pribadi saya, saya menerima banyak inspirasi dari berbagai artikel dan konferensi. Saya ingin menyebutkan presentasi oleh Eberhard Wolff "Arsitektur dan Implementasi Berbasis Acara dengan Kafka dan Atom" (arsitektur acara dan implementasi menggunakan Kafka dan Atom). Terutama tentang Sumber Acara dan acara apa , yang sangat relevan dalam konteks posting ini. Contoh toko online juga terinspirasi oleh ceramah ini.

Jika Anda ingin informasi lebih lanjut, Anda dapat merujuk ke sumber daya ini:


: « : ».

More articles:


All Articles