Bir komut bir CQ [R] S modelinde ne kadar ayrıntılı olmalıdır?


17

WCF tabanlı SOA'nın bir kısmını bir servis veri yolu modeline (muhtemelen nServiceBus) geçirmek için bir proje ve Komut Sorgu Ayrımı elde etmek için bazı temel pub-sub kullanarak düşünüyorum .

SOA'da, hatta servis otobüsü modellerinde yeni değilim, ancak yakın zamana kadar "ayırma" kavramımın çalışma zamanı veritabanı yansıtma ve çoğaltma ile sınırlı olduğunu itiraf ediyorum. Yine de, bu fikre ilgi duyuyorum, çünkü bariz dezavantajların birçoğunu (özellikle de uygun işlem desteğinin olmaması) ortadan kaldırırken , sonunda tutarlı bir sistemin tüm faydalarını sağlıyor gibi görünüyor .

Ben temelde Udi Dahan da konuyla ilgili bir çok okumak ettik (Microsoft dünyasında en azından) ESB mimarileri üzerinde gurusu, ama aslında diyor bir şey Kafamı kurcalayan:

Üzerinde daha fazla alana sahip daha büyük varlıklar elde ettikçe, aynı varlıklar ile çalışan daha fazla aktör elde ederiz ve bir şeyin herhangi bir zamanda herhangi bir özelliğine dokunma olasılığı arttıkça eşzamanlılık çatışmalarının sayısı artar.

[...]

CQRS'nin temel bir unsuru, kullanıcılarımızın niyetini yakalamamızı sağlamak için kullanıcı arayüzünün tasarımını yeniden düşünmektir; evli. Yukarıda gördüğümüz gibi, veri değişiklikleri için Excel benzeri bir kullanıcı arayüzü kullanmak amacı yakalamaz.

- Udi Dahan, Arındırılmış CQRS

Alıntıda anlatılan perspektiften, bu mantıkla tartışmak zor. Fakat SOA'ya göre tahıllara karşı çıkıyor gibi görünüyor. Bir SOA'nın (ve genel olarak gerçekten hizmetlerin), diğer birçok avantajın yanı sıra ağ sohbetini en aza indirgemek için kaba mesajlarla uğraşması bekleniyor .

İyi mesaj kuyruğu olan ve RPC'nin bagajlarının hiçbirine sahip olmayan yüksek oranda dağıtılmış sistemleriniz olduğunda ağ sohbetinin daha az sorun olduğunu anlıyorum, ancak sorunu tamamen ortadan kaldırmak akıllıca görünmüyor. Udi, neredeyse her özellik değişikliğinin (yani alan güncellemesi) kendi komutu olması gerektiğini söylüyor; bu, bir kullanıcının yüzlerce veya binlerce kombine varlığı ve özelliği geleneksel olarak olduğu gibi potansiyel olarak güncellediğini hayal etmek zor internet servisi.

SQL Server'daki bir toplu güncelleştirme, yüksek düzeyde parametreleştirilmiş iyi bir sorgu, tablo değerli parametre veya bir hazırlama tablosuna toplu ekleme verildiğinde saniyenin bir kısmını alabilir; bu güncellemelerin tümünü birer birer işlemek yavaş, yavaş, yavaş ve OLTP veritabanı donanımı, ölçeklendirme / genişletme için en pahalı olanıdır.

Bu rakip kaygıları uzlaştırmanın bir yolu var mı? Yanlış düşünüyor muyum? Bu sorunun CQS / ESB dünyasında iyi bilinen bir çözümü var mı?

Değilse, bir Komuta'daki ayrıntı düzeyinin "doğru seviyesinin" ne olması gerektiğine nasıl karar verilir? Bazı "standart" bir başlangıç ​​noktası olarak kullanılabilir - veritabanlarında 3NF gibi - ve sadece dikkatli profil oluşturma potansiyel olarak önemli bir performans avantajı önerdiğinde sapar mı?

Ya da bu, çeşitli uzmanlar tarafından ifade edilen birkaç güçlü düşünceye rağmen, gerçekten sadece bir fikir meselesi olan şeylerden biri mi?

Yanıtlar:


7

"Her özellik değişikliği" konusunda

Bence bu noktayı kaçırdın. Bay Udi Dahan, kullanıcının bir emir olarak niyetini yakalamanız gerektiğini söylüyor. Son kullanıcı, bir müşterinin taşındığını belirtebilme konusunda endişe duymaktadır. Komutun bir müşteri kimliği içerebileceği bağlama bağlı olarak, yeni adres (caddeye, sokak numarasına, posta koduna bölünür), isteğe bağlı olarak yeni bir telefon numarası (taşıdığınızda nadir değildir - belki de tüm bu cep telefonlarında daha az) . Bu neredeyse bir özellik değil. Daha iyi bir soru "komutları nasıl tasarlayabilirim?". Onları davranışsal bir perspektiften tasarlıyorsunuz. Son kullanıcının tamamlamaya çalıştığı her kullanım durumu, akış, görev, bir veya daha fazla komutla yakalanır. Bu komutlarla hangi veriler giderilir, siz onları daha ayrıntılı olarak düşünmeye başlarsınız. Dikkat edilmesi gereken şey, "komutu bölmeniz gerektiğinin bir göstergesi olabilir . Umarım komut ayrıntı düzeyi konusunda bu standardı asla bulamazsınız . İyi soru olsa!


Bu tanım hala benim için çok keyfi geliyor; bir CSR'nin kavramsal modeli, adresi ve posta kodunu bir araya getirdiğiniz şekilde, tercih edilen durumu ve savaş durumunu bir araya getirebilir. Saçları bölmek istemiyorum, sadece farklı davranışlar olup olmadıklarını gerçekten anlamak için, aşağı yönde etkileri tahmin edebilmeniz ve OTOH'nin ESB ve CQS ve pub / sub, aşağı yönde neler olduğunu bilmemeniz veya umursamamanızdır. Cevabınız için teşekkür ederim, takdir ediyorum, şimdiye kadar daha fazla aydınlandığımı söyleyemem ...
Aaronaught

@Aaronaught: tanım olan rasgele. Bir Komutun ayrıntı düzeyi, sizin senaryo için anlamlı olan her şey olmalıdır . Herkese uyan tek beden yok. Kullanıcı arayüzünde bulunan vakaları veya görevleri veya eylemleri kullanmak için komutları eşleştirme gibi birkaç yönerge vardır - bir diğeri daha az ayrıntılı komutlara göre daha ayrıntılı komutları tercih etmektir (özellikle Yves'in mantık kontrol akışı olarak yorumlanan verilere karşı dikkatli olması nedeniyle) - ama zor ve hızlı bir kural yok. "Bir kullanıcının yüzlerce veya binlerce birleştirilmiş varlığı ve özelliği potansiyel olarak güncellediği" gerçek bir senaryo var mı?
quentin-starin

Bütün mesele bu! Birlikte topaklanma. Davranışlara göre bölün! Komuta / son kullanıcının amacına uymayan verileri koymayın. Ve bu alt sistemlerle ilgili değil.
Yves Reynhout

@qes: Sistemlerimizde çok gerçek ve çok gerekli olan böyle senaryolar var. Bunu olabildiğince basit bir şekilde ifade etmek için, tüm veri dizilerini değiştirmeleri gerekir ve bu diziler sadece diziler olarak anlamlıdır. Tabii ki genellikle bu değişiklikleri kayda göre kaydetmezler, bir kısmına algoritma uygularlar ve sonra birkaç istisnayı düzeltirler. Belki de bu, CQS'nin başlaması için uygun bir senaryo değildir, ancak bu karar daha geniş sorumun bir alt kümesidir.
Aaronaught

1
@qes: Yeterince adil ve bu kendi başına bir cevap. Mantıksal bir işlem kavramını kesinlikle anlıyorum (mevcut hizmetler bu şekilde modellenmiştir), sanırım CQS'nin bir işlemi nasıl tanımlamanız gerektiği konusundaki kurallardan birkaçını değiştirdiğini düşünmüştüm . "Geleneksel" SOA mümkün olan en kaba tanımdan başlıyor ve gerekirse soyutlama merdivenden aşağı iniyor gibi görünüyor; şimdiye kadar CQS anlayışım bunun tersini gösteriyor, mümkün olan en ayrıntılı tanımdan başlıyor ve RPC veya kontrol akışına çok benziyorsa soyut.
Aaronaught

2

Udi'nin karşılaşmaya çalıştığı mesaj, CQRS'nin CRUD'dan daha fazlası olduğu. Bu kaydı neden oluşturdum? Bu kaydı neden değiştiriyorum? Neden siliniyor / silinmiş olarak işaretleniyor?

Komutlar, kullanıcının sistemle yaptığı eylemlere / kullanım örneklerine karşılık gelmeli ve yalnızca bunu değiştirmek yerine eylemin amacını ifade etmelidir. Ayrıca, daha ince taneli gibi görünebilir, ancak ilk göründüğünden çok daha kaba olabilir. Örneğin, altın statüsüne yükseltme birkaç özellikte bir değişiklik içerebilir ve diğer bazı agregalar da karşılık gelen olaya yanıt olarak değişebilir.

CQRS, Hizmet katmanındaki işletmenin dilini yakalamakla ilgilidir, bu nedenle kullanıcı arayüzü, altın durum yükseltmesini yaptığımda veya gönderi taşıyıcı tarafından teslim edilemez olarak işaretlendiğinde veya çalışan terfi edildiğinde ne olacağı konusunda endişelenmek zorunda kalmaz teknoloji grubunun yöneticisine. Teknik olarak şimdi Olay Sağlama'dan bahsediyorum ama sen sapmamı alıyorsun. Daha belirgin mesajlar vardır, ancak bunlar standart CUD'dan daha ince taneli olmak zorunda değildir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.