cqrs

Xendor

Xendor adalah kerangka kerja inti .NET yang dapat digunakan untuk membuat desain yang sederhana dan bersih dengan menegakkan tanggung jawab tunggal dan pemisahan kekhawatiran. Fitur canggihnya sangat ideal untuk Domain Driven Design (DDD), Command Query Responsibilty Segragation (CQRS) dan Sourcing Event. Xendor juga memiliki integrasi RabbitMQ.

Apa itu CQRS?

Segregasi tanggung jawab komando adalah pola yang memberitahu kita untuk memisahkan operasi yang bermutasi dari yang menanyakannya. Ini berasal dari Command Query Pemisahan (CQS) CQS menyatakan bahwa hanya ada dua jenis metode pada kelas: yang bermutasi keadaan dan mengembalikan kekosongan dan yang mengembalikan keadaan tetapi tidak mengubahnya.

CQRS adalah pola yang Anda terapkan? Bagian dalam? Layanan/Aplikasi Anda dan Anda dapat menerapkannya hanya pada bagian dari layanan Anda.

Itu bukan cqrs

Itu bukan konsistensi akhirnya

Itu tidak acara

Itu bukan pesan

Itu tidak memiliki model terpisah untuk membaca dan menulis

Juga tidak menggunakan sumber acara.

Pro & kontra cqrs

Pro:

• Kinerja dan skalabilitas sistem Anda yang lebih baik.
• Penanganan akses bersamaan yang lebih baik.
• Skalabilitas tim yang lebih baik.
• Model domain yang kurang kompleks dan model kueri sederhana.

Kontra:

• Model baca dan tulis harus disinkronkan.
• biaya pemeliharaan dan administrasi jika Anda memilih dua mesin yang berbeda untuk dibaca dan untuk sisi tulis.
• Konsistensi akhirnya tidak selalu diizinkan.

Apa itu sumber acara?

Alih-alih menyimpan hanya keadaan data saat ini dalam domain, gunakan toko saja untuk merekam serangkaian tindakan lengkap yang diambil pada data itu. Toko bertindak sebagai sistem catatan dan dapat digunakan untuk mewujudkan objek domain. Ini dapat menyederhanakan tugas dalam domain yang kompleks, dengan menghindari kebutuhan untuk menyinkronkan model data dan domain bisnis, sambil meningkatkan kinerja, skalabilitas, dan responsif. Ini juga dapat memberikan konsistensi untuk data transaksional, dan memelihara jalur audit penuh dan sejarah yang dapat memungkinkan tindakan kompensasi.

Di sistem manakah layak menggunakan sumber acara?

• Sistem Anda memiliki banyak perilaku yang bukan crud biasa.
• Menciptakan kembali keadaan historis objek sangat penting
• Pengguna bisnis melihat keunggulan memiliki riwayat lengkap untuk statistik, pembelajaran mesin atau tujuan lain.
• Domain Anda paling baik dijelaskan oleh acara (misalnya, aplikasi untuk melacak kegiatan kendaraan bantuan).

Pros Sumber Acara & Kontra

Pro:

• Tambahkan model hanya bagus untuk kinerja, skalabilitas
• Tidak ada kebuntuan
• Acara (fakta) dipahami dengan baik oleh ahli bisnis, beberapa domain secara inheren bersumber dari acara: akuntansi, perawatan kesehatan, perdagangan
• Jejak Audit Gratis
• kita bisa mendapatkan keadaan objek kapan saja
• mudah diuji dan debug
• Model Data dipisahkan dari model domain
• Tidak ada ketidaksesuaian impedansi (model objek vs model data)
• fleksibilitas? Banyak model domain yang berbeda dapat dibangun dari aliran peristiwa yang sama
• kita dapat menggunakan model ini dengan peristiwa pembalikan, peristiwa retroaktif
• Tidak ada lagi Orms? Berkat fakta bahwa objek kami dibangun dari acara, kami tidak harus mencerminkannya dalam database relasional

Kontra:

• Bukan cara alami bagi pengembang untuk mengelola negara dan membangun agregat, membutuhkan waktu untuk membiasakan diri
• Permintaan di luar satu agregat sedikit lebih sulit (Anda harus membangun proyeksi untuk setiap jenis kueri yang ingin Anda tambahkan ke sistem),
• Perubahan skema peristiwa jauh lebih sulit daripada dalam kasus model relasional (kurangnya alat migrasi skema standar)
• Anda harus mempertimbangkan penanganan versi dari awal.

Sumber Acara - Proyeksi

Proyeksi adalah konsep penting saat membangun sistem peristiwa-sentris. Pada saat yang sama, ini sangat sederhana.

Proyeksi adalah tentang memperoleh keadaan saat ini dari aliran peristiwa.

Misalnya, pertimbangkan suatu situasi, di mana aliran acara diterbitkan oleh server kepada semua pelanggan. Acara ini terkait dengan pendaftaran pengguna dan terlihat seperti:

UseraddedtoAccount

{
 "userId" : 55 ,
 "username" : " alemol " ,
 "name" : " Alejandro " ,
 "lastName" : " Moline "
}

UserverIfiedemail

{
 "userId" : 55 ,
 "email" : " [email protected] "
}

Userupdated

{
 "userId" : 55 ,
 "lastName" : " Molines "
}

Kami dapat melampirkan pelanggan untuk melakukan aliran acara ini untuk memproyeksikan aliran ini menjadi model baca yang persisten, yang digunakan untuk melayani detail pengguna di UI Web. Model baca terakhir bisa terlihat seperti:

{
 "userId" : 55 ,
 "username" : " alemol " ,
 "email" : " [email protected] " ,
 "name" : " Alejandro " ,
 "lastName" : " Molines "
}

CQRS dengan Sourcing Acara (CQRS-ES)

Beri bintang!

Jika Anda suka atau menggunakan proyek ini, silakan berikan bintang. Terima kasih!

Saya menemukan masalah atau saya memiliki permintaan perubahan

Jangan ragu untuk membuat masalah di GitHub. Kontribusi, permintaan tarik lebih dari disambut!

Xendor adalah Hak Cipta © 2019 Alejandro Molines dan kontributor lainnya di bawah lisensi MIT.