Bagaimana seharusnya granular dalam model CQ [R] S?


17

Saya sedang mempertimbangkan proyek untuk memigrasi bagian dari SOA berbasis WCF kami ke model bus layanan (mungkin nServiceBus) dan menggunakan beberapa pub-sub dasar untuk mencapai Pemisahan Command-Query .

Saya bukan orang baru dalam SOA, atau bahkan untuk model bus servis, tetapi saya akui bahwa hingga saat ini konsep "pemisahan" saya terbatas pada mirroring dan replikasi run-of-the-mill database. Tetap saja, saya tertarik pada ide itu karena tampaknya memberikan semua manfaat dari sistem yang pada akhirnya konsisten sementara menghindari banyak kelemahan yang jelas (terutama kurangnya dukungan transaksional yang tepat).

Saya sudah membaca banyak tentang subjek dari Udi Dahan yang pada dasarnya adalah guru pada arsitektur ESB (setidaknya di dunia Microsoft), tetapi satu hal yang dia katakan benar-benar membingungkan saya:

Ketika kita mendapatkan entitas yang lebih besar dengan lebih banyak bidang pada mereka, kita juga mendapatkan lebih banyak aktor yang bekerja dengan entitas yang sama, dan semakin tinggi kemungkinan bahwa sesuatu akan menyentuh beberapa atribut mereka pada waktu tertentu, meningkatkan jumlah konflik konkurensi.

[...]

Elemen inti dari CQRS adalah memikirkan kembali desain antarmuka pengguna untuk memungkinkan kami menangkap maksud pengguna kami sehingga menjadikan pelanggan lebih disukai adalah unit kerja yang berbeda bagi pengguna daripada menunjukkan bahwa pelanggan telah pindah atau bahwa mereka telah mendapatkan menikah. Menggunakan UI seperti Excel untuk perubahan data tidak menangkap maksud, seperti yang kita lihat di atas.

- Udi Dahan, Klarifikasi CQRS

Dari perspektif yang dijelaskan dalam kutipan, sulit untuk berdebat dengan logika itu. Tapi tampaknya bertentangan dengan SOA. SOA (dan benar-benar layanan pada umumnya) seharusnya berurusan dengan pesan kasar sehingga meminimalkan obrolan jaringan - di antara banyak manfaat lainnya.

Saya menyadari bahwa obrolan jaringan tidak terlalu menjadi masalah ketika Anda memiliki sistem yang sangat terdistribusi dengan antrian pesan yang baik dan tidak ada satu pun bagasi RPC, tetapi tampaknya tidak bijaksana untuk mengabaikan masalah ini sepenuhnya. Udi hampir mengatakan bahwa setiap perubahan atribut (yaitu pembaruan lapangan) harus menjadi perintahnya sendiri, yang sulit dibayangkan dalam konteks satu pengguna yang berpotensi memperbarui ratusan atau ribuan entitas dan atribut gabungan seperti yang sering terjadi dengan tradisional layanan web.

Satu pemutakhiran batch dalam SQL Server dapat mengambil sepersekian detik dari diberikan kueri yang sangat parameter, parameter tabel bernilai atau memasukkan massal ke tabel staging; memproses semua pembaruan ini satu per satu adalah lambat, lambat, lambat , dan perangkat keras database OLTP adalah yang paling mahal dari semua untuk meningkatkan / memperkecil.

Apakah ada cara untuk merekonsiliasi masalah yang saling bersaing ini? Apakah saya memikirkannya dengan cara yang salah? Apakah masalah ini memiliki solusi terkenal di dunia CQS / ESB?

Jika tidak, lalu bagaimana seseorang memutuskan "tingkat yang tepat" dari granularitas dalam sebuah Perintah seharusnya? Apakah ada beberapa "standar" yang dapat digunakan sebagai titik awal - semacam 3NF dalam database - dan hanya menyimpang ketika pembuatan profil yang hati-hati menunjukkan manfaat kinerja yang berpotensi signifikan?

Atau mungkinkah ini salah satu dari hal-hal yang, meskipun beberapa pendapat kuat diungkapkan oleh berbagai ahli, benar-benar hanya masalah pendapat?

Jawaban:


7

Pada topik "setiap perubahan atribut"

Saya kira kamu melewatkan poin itu. Pak Udi Dahan mengatakan Anda harus menangkap maksud pengguna sebagai perintah. Pengguna akhir khawatir dapat menunjukkan bahwa pelanggan telah pindah. Bergantung pada konteks bahwa perintah dapat berisi identifikasi pelanggan, alamat baru (dipisah menjadi jalan, nomor jalan, kode pos, ...), opsional nomor telepon baru (tidak jarang ketika Anda bergerak - mungkin kurang begitu dengan semua ponsel ini) . Itu bukan satu atribut. Pertanyaan yang lebih baik adalah "bagaimana cara mendesain perintah?". Anda mendesainnya dari perspektif perilaku. Setiap kasus penggunaan, aliran, tugas yang coba diselesaikan oleh pengguna akhir, akan ditangkap dalam satu atau beberapa perintah. Data apa yang muncul dengan perintah-perintah itu datang secara alami, saat Anda mulai memikirkannya secara lebih rinci. Yang harus diperhatikan adalah data yang ditafsirkan sebagai "mungkin merupakan indikasi bahwa Anda perlu memisahkan perintah. Saya harap Anda tidak pernah menemukan standar yang berkaitan dengan perintah granularity. Pertanyaan yang bagus!


Definisi ini masih terasa sangat sewenang-wenang bagi saya; model konseptual CSR dapat menyatukan status pilihan dan status bela diri bersamaan dengan cara Anda menyatukan alamat dan kode pos. Saya tidak bermaksud memecah rambut, sepertinya bagi saya untuk benar-benar memahami jika mereka memiliki perilaku yang berbeda, Anda harus dapat memprediksi efek hilir, dan OTOH seluruh gagasan ESB dan CQS dan pub / Sub adalah bahwa Anda tidak seharusnya tahu atau peduli apa yang terjadi di hilir. Terima kasih atas jawaban Anda, saya sangat menghargainya, meskipun saya tidak bisa mengatakan saya merasa lebih tercerahkan sejauh ini ...
Aaronaught

@Aaronaught: Definisi ini arbitrer. Granularity dari Command haruslah apa pun yang masuk akal untuk skenario khusus Anda . Tidak ada satu ukuran yang cocok untuk semua. Ada beberapa pedoman, seperti perintah yang cocok untuk menggunakan kasus atau tugas atau tindakan yang tersedia di UI - yang lain adalah lebih memilih perintah granular lebih dari perintah granular kurang (khususnya ketika Yves mengatakan waspada terhadap data yang ditafsirkan sebagai aliran kontrol logika) - tetapi tidak ada aturan yang keras dan cepat. Apakah ada skenario aktual di mana "satu pengguna berpotensi memperbarui ratusan atau ribuan entitas dan atribut gabungan"?
quentin-starin

Itulah intinya! Jangan menyatu. Membagi sesuai perilaku! Jangan letakkan data dalam perintah yang tidak selaras dengan maksud perintah / pengguna akhir. Dan itu bukan tentang sistem hilir.
Yves Reynhout

@ qes: Dalam sistem kami ada beberapa skenario seperti itu, sangat nyata dan sangat diperlukan. Untuk menyatakannya sesederhana mungkin, mereka perlu memodifikasi seluruh urutan data dan urutan ini hanya masuk akal sebagai urutan. Tentu saja mereka biasanya tidak membuat perubahan ini menjadi catatan, mereka menerapkan beberapa algoritma untuk sebagian besar dan kemudian memperbaiki beberapa pengecualian. Mungkin ini bukan skenario yang tepat untuk memulai CQS, tetapi keputusan itu hanyalah sebagian dari pertanyaan saya yang lebih luas.
Aaronaught

1
@ qes: Cukup adil, dan itu adalah jawaban. Saya tentu saja memahami konsep operasi logis (begitulah layanan yang ada dimodelkan), saya kira saya baru saja khawatir bahwa CQS tampaknya mengubah beberapa aturan tentang bagaimana Anda harus mendefinisikan operasi. SOA "Tradisional" tampaknya mulai dari definisi kasar yang mungkin dan turunkan tangga abstraksi jika perlu; pemahaman saya tentang CQS sejauh ini tampaknya menunjukkan yang sebaliknya, mulai dari definisi yang paling granular mungkin dan abstrak jika terlihat terlalu mirip dengan RPC atau aliran kontrol.
Aaronaught

2

Pesan yang Udi coba sampaikan adalah bahwa CQRS lebih dari sekadar CRUD. Mengapa saya membuat catatan ini? Mengapa saya mengubah catatan ini? Mengapa itu dihapus / ditandai sebagai dihapus?

Perintah harus sesuai dengan kasus tindakan / penggunaan yang dibuat pengguna dengan sistem dan menyatakan maksud tindakan daripada hanya mengatakan ubah ini. Juga, itu mungkin terlihat seperti butiran yang lebih halus tetapi bisa jadi lebih kasar daripada yang pertama kali muncul. Misalnya peningkatan ke status emas mungkin melibatkan perubahan ke beberapa atribut dan sejumlah agregat lainnya bahkan mungkin merespons dan berubah sebagai respons terhadap peristiwa terkait.

CQRS adalah tentang menangkap bahasa bisnis di lapisan Layanan sehingga UI tidak perlu khawatir tentang apa yang terjadi ketika saya membuat peningkatan status emas atau pengiriman telah ditandai sebagai tidak terkirim oleh operator, atau karyawan tersebut telah dipromosikan kepada manajer grup teknologi. Yah secara teknis saya berbicara tentang Event Sourcing sekarang, tetapi Anda mengerti maksud saya. Ada lebih banyak pesan yang berbeda tetapi tidak selalu lebih baik daripada CUD standar.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.