Etki alanı açısından zengin bir uygulamada raporlama ve gösterge tabloları için verilerin alınması için en iyi uygulama veya tasarım desenleri

Öncelikle, bunun ihmal edilmiş bir soru / alan gibi göründüğünü söylemek istiyorum, bu yüzden bu sorunun iyileştirilmesi gerekiyorsa, bunu başkalarına fayda sağlayabilecek harika bir soru yapmama yardımcı olun! Sadece denemek için fikirler değil, bu sorunu çözen çözümler uygulayan insanlardan tavsiye ve yardım arıyorum.

Tecrübelerime göre, bir uygulamanın iki tarafı vardır - büyük ölçüde etki alanı kullanan ve kullanıcıların etki alanı modeli (uygulamanın "motoru") ve kullanıcıların raporlama tarafı ile zengin etkileşimde bulunduğu "görev" tarafı Görev tarafında olanlara dayanarak veri almak.

Görev tarafında, zengin bir etki alanı modeline sahip bir uygulamanın etki alanı modelinde iş mantığına sahip olması ve veritabanı çoğunlukla kalıcılık için kullanılması gerektiği açıktır. Kaygıların ayrılması, her kitap hakkında yazılmıştır, ne yapacağımızı biliyoruz, harika.

Peki ya raporlama tarafı? Veri ambarları kabul edilebilir mi, yoksa veritabanında iş mantığını ve verinin kendisini içerdikleri için kötü tasarım mı? Veriyi veri tabanından veri ambarı verilerine toplamak için verilere iş mantığı ve kuralları uygulamış olmalısınız ve bu mantık ve kurallar etki alanı modelinizden gelmedi, veri toplama işlemlerinizden geldi. Yanlış mı?

İş mantığının kapsamlı olduğu büyük finansal ve proje yönetimi uygulamaları üzerinde çalışıyorum. Bu verileri raporlarken, rapor / gösterge tablosu için gereken bilgileri almak için sıkça bir sürü topluluğa katılırım ve toplanmaların içinde çok fazla iş mantığı vardır. Performans uğruna, çok toplanmış tablolarla ve saklı yordamlarla yapıyorum.

Örnek olarak, aktif projelerin bir listesini göstermek için bir rapor / gösterge panosunun gerekli olduğunu varsayalım (10.000 proje düşünün). Her projenin, onunla birlikte gösterilen bir dizi metriye ihtiyacı olacaktır, örneğin:

1. toplam bütçe
2. bugüne kadarki çaba
3. pişirme oranı
4. mevcut yanma oranında bütçe tükenme tarihi
5. vb.

Bunların her biri çok fazla iş mantığı içerir. Ve ben sadece sayıların çarpılması ya da basit bir mantıktan bahsetmiyorum. Bütçeyi alabilmek için, her çalışanın zamanı (bazı projelerde, diğerinin çarpanı var), harcamaları ve uygun işaretlemeleri vb. İçeren 500 farklı oranlı bir ücret listesi uygulamak zorundasınız. mantık geniş. Bu verileri müşteri için makul bir sürede elde etmek için çok fazla toplama ve sorgulama ayarlama gerekiyordu.

Bu önce etki alanı üzerinden mi yürütülmeli? Peki ya performans? Düzgün SQL sorgularıyla bile, bu verileri müşterinin makul bir süre içinde görüntülemesi için yeterince hızlı bir şekilde alıyorum. Tüm bu etki alanı nesnelerini yeniden sulandırıyorsam ve verilerini uygulama katmanında karıştırıp eşleştiriyorsa veya veriyi uygulama katmanında birleştirmeyi deniyorsam, bu verileri müşteriye yeterince hızlı almaya çalışacağımı hayal edemiyorum.

Bu gibi durumlarda SQL veri toplamada iyidir ve neden kullanmıyorsunuz? Ancak, etki alanı modelinizin dışında bir iş mantığınız var. İşletme mantığında yapılacak herhangi bir değişiklik, etki alanı modelinizde ve raporlama toplama şemalarınızda değiştirilmelidir.

Etki alanı odaklı tasarım ve iyi uygulamalarla ilgili olarak herhangi bir uygulamanın raporlama / gösterge tablosunu nasıl tasarlayacağımı gerçekten yitiriyorum.

MVC etiketini ekledim çünkü MVC tasarım tadı du jour ve mevcut tasarımımda kullanıyorum, ancak raporlama verilerinin bu tür uygulamalara nasıl uyduğunu bulamıyorum.

Bu alanda herhangi bir yardım arıyorum - kitaplar, tasarım desenleri, google anahtar kelimeler, makaleler, her şey. Bu konuda herhangi bir bilgi bulamıyorum.

EDİT VE DİĞER BİR ÖRNEK

Bugün rastladığım bir başka mükemmel örnek. Müşteri, Müşteri Satış Ekibi için bir rapor istiyor. Basit bir metrik gibi görünen şeyi istiyorlar:

Her bir Satış elemanı için, bugüne kadarki yıllık satışları nedir?

Ama bu karmaşık. Her satış elemanı birden fazla satış fırsatına katıldı. Bazıları kazandılar, bazıları kazanmadı. Her bir satış fırsatında, her biri rolleri ve katılımları için satışlar için bir kredi yüzdesi tahsis edilmiş birden fazla satış elemanı vardır. Şimdi bunun için etki alanından geçtiğinizi hayal edin ... bu verileri her bir Satış görevlisinin veritabanından almak için yapmanız gereken nesne rehidrasyonunun miktarı:

Hepsini al SalesPeople->
Her biri için SalesOpportunities- -
Her biri için satış yüzdesini almak ve Satış tutarlarını hesaplamak ve
sonra tüm SalesOpportunitySatış tutarlarını eklemek.

Ve bu BİR metrik. Veya hızlı ve verimli bir şekilde yapabilen ve hızlı olmasını sağlayacak bir SQL sorgusu yazabilirsiniz.

EDIT 2 - CQRS Deseni

CQRS Örüntüsünü okudum ve merak uyandırırken, Martin Fowler bile test edilmediğini söylüyor. Peki, bu sorun geçmişte nasıl çözüldü? Bu, bir noktada veya başka bir yerde herkes tarafından karşı karşıya kalmış olmalı. Başarılı bir geçmişe sahip olan yerleşik veya iyi giyilmiş bir yaklaşım nedir?

Düzenleme 3 - Raporlama Sistemleri / Araçları

Bu bağlamda göz önünde bulundurulması gereken başka bir şey de raporlama araçlarıdır. Raporlama Servisleri / Kristal Raporlar, Analiz Servisleri ve Cognoscenti, vb. Hepsi SQL / veritabanından veri bekliyor. Verilerinizin daha sonra bunlar için işinizden geleceğinden şüpheliyim. Ve onlar ve onlar gibi diğerleri, birçok büyük sistemde raporlamanın hayati bir parçasıdır. Bunlara ait veriler, bu sistemler için veri kaynağında ve muhtemelen raporların kendisinde iş mantığının olduğu yerlerde, doğru şekilde nasıl işlenir?

Bu çok glib bir cevap, ancak konunun tam anlamıyla doğru:

DDD açısından Sınırlı Bağlam olarak rapor etmeyi düşünebilirsiniz, bu nedenle “THE” etki alanı modeli olarak düşünmek yerine, birden fazla modele sahip olmanın doğru olduğunu düşünmeye istekli olmalısınız. Bu nedenle, evet, raporlama etki alanında raporlama iş mantığı varsa, işlem alanı için işlemsel işlem mantığı olması sorun değil.

Sorunun yanı sıra, uygulama kodunda etki alanı modeline göre SQL saklı yordamları, işlem sisteminde olduğu gibi raporlama sistemi için de aynı avantaj ve dezavantajların geçerli olduğunu söyleyin.

Soruya bir ödül eklediğinizi gördüğümden, soruyu tekrar okudum ve bu konuda özel bir kaynak istediğinizi fark ettim, bu yüzden konuyla ilgili diğer Yığın Taşması sorularına bakmanızı önermekle başlayacağımı düşündüm. ve bunu buldum https://stackoverflow.com/questions/11554231/how-does-domain-driven-design-handle-reporting

Bunun genel özeti, DDY ile tutarlı olan sisteminiz için bir CQRS kullanmak ve raporlama yapmanın bir yolu olarak sorgu tarafı sorumluluklarına dayanmaktır, ancak bunun yararlı bir cevap olduğundan emin değilim. senin durumun.

Ayrıca , http://www.martinfowler.com/bliki/ReportingDatabase.html dosyasını buradan buldum. Http://groups.yahoo.com/neo/groups/domaindrivendesign/conversations/topics/2261

İşte konuyla ilgili ACM'den ilginç bir yazı: http://dl.acm.org/citation.cfm?id=2064685 ancak bir ödeme duvarının gerisinde kaldı, bu yüzden gerçekten okuyamıyorum (ACM üyesi değil :().

Benzer bir soruya cevap burada da var: https://stackoverflow.com/questions/3380431/cqrs-ddd-synching-reporting-database

ve bu bir: http://snape.me/2013/05/03/applying-domain-driven-design-to-data-warehouses/

Bu yardımcı olur umarım!

Sorunuzdan anladığım şudur: Günlük görev için başvuru var

Görünüm >> Kontrolör >> Model (BL) >> Veritabanı (Veri)

Raporlama amaçlı başvuru

Görünüm >> Kontrolör >> Model >> Veritabanı (Veri + BL)

Bu nedenle, ' görev uygulaması ' için BL’de yapılan değişiklik, “ raporlama ” BL’da da değişime neden olacaktır . Bu senin gerçek sorunun değil mi? Şey, bu iki kez değişiklik yapmanın sorun değil, yine de almanız gereken acı. Bunun nedeni, her iki BL'nin de kendi endişeleriyle ayrılmasıdır. Biri veri toplamak için, biri veri toplamak için. Ayrıca, orijinal BL ve toplayıcı BL'niz farklı teknoloji veya dilde ( C # / java ve SQL proc ) yazılacaktır . Kaçış yok.

Özel olarak raporlamayla ilgili olmayan başka bir örnek verelim. Bir şirketin XXX, yorum için tüm kullanıcıların postalarını izler ve bu bilgileri pazarlama şirketlerine satar. Şimdi yorumlama için bir BL ve pazarlama şirketleri için veri toplama için bir BL olacaktır. Endişeler, her iki BL için de farklıdır. Yarın BL'ları Küba'dan gelen postaların göz ardı edilmesi gerektiği şekilde değişirse, iş mantığı her iki tarafta da değişecektir.

Raporlama, gevşek bir şekilde konuşmak için sınırlı bir içerik veya bir alt etki alanıdır. İş zekası elde etmek için veri toplama / toplama ve işleme gibi bir iş gereksinimini çözer.

Bu alt etki alanını nasıl uygulayacağınız, muhtemelen bunu yapabileceğiniz (en) mimari olarak doğru yöntemle altyapınızın izin vereceği şey arasında bir denge olacaktır. Eskiden başlamak ve ikincisine sadece gerektiği kadar ilerlemek hoşuma gidiyor.

Muhtemelen bunu çözdüğünüz iki ana soruna ayırabilirsiniz:

1. Toplama veya depolama verileri. Bu, bazı veri kaynağını işlemeli ve bilgileri başka bir veri kaynağında depolanacak şekilde birleştirmelidir.

2. İş zekası sağlamak için toplu veri kaynağını sorgulamak.

Bu sorunların hiçbiri belirli bir veritabanına veya depolama motoruna referans vermiyor. Etki alanı katmanınız yalnızca altyapı katmanınızda çeşitli depolama bağdaştırıcıları tarafından uygulanan arabirimlerle ilgileniyor olmalıdır.

Birkaç hareketli parçaya bölünmüş çeşitli işçilere veya bazı planlı işlere sahip olabilirsiniz:

• Sorgulanacak bir şey
• Toplanacak bir şey
• Saklayacak bir şey

Umarım bazı CQRS'lerin orada parladığını görebilirsiniz.

Raporlama tarafında, sadece sorgulama yapması gerekir, fakat asla doğrudan veritabanına girmemesi gerekir. Arayüzlerinizi ve etki alanı katmanınızı buradan inceleyin. Bu, birincil görevlerinizle aynı problem alanı değil, fakat yine de burada uymak istediğiniz bir mantık olmalı.

Doğrudan veritabanına daldığınızda, buna daha çok güvenirsiniz ve sonuçta orijinal uygulamanızın veri gereksinimlerini etkileyebilir.

Ayrıca, en azından benim için kesinlikle sorguları veya saklı yordamları değil, test yazmayı ve kod geliştirmeyi tercih ediyorum. Ayrıca kesinlikle gerekli olana kadar kendimi belirli aletlere kilitlememeyi de seviyorum.

İnternet de dahil olmak üzere geniş alan ağları üzerinden büyük miktarlarda bilgi almak, yanıtın gecikmesinden, veri hizmet kaynaklarına doğrudan bellek erişiminin yetersiz kalmasından ve hata toleransından kaynaklanan sorunlardan dolayı sorunludur.

Bu soru, büyük miktarda veri getiren sorgulardan elde edilen sonuçların ele alınmasına ilişkin tasarım modelini açıklar. Tipik olarak bu sorgular, bir uzak sunucuda bulunan ilişkisel bir veri tabanına bir veya daha fazla orta katman içeren geniş bir alan ağı (veya İnternet) boyunca bir müşteri işlemi ile yapılır.

Çözüm, veri kümelerini çaprazlamak için yineleyicilerin kullanılması ve müşteriye uygun bir soyutlama seviyesi sağlanması, veri alt kümelerinin çift tamponlanması, çok iş parçacıklı veri alımı ve sorgu dilimleme dahil veri toplama stratejilerinin bir kombinasyonunun uygulanmasını içerir.

Operasyonel / işlemsel veri depolarını raporlamalardan ayırmak tipiktir. İkincisi, yasal nedenlerle (örneğin finansal denetim için yedi yıllık finansal veri) verileri saklama gereklilikleri olabilir ve bunların tümünü işlem veri deponuzda istemiyorsunuz.

Böylece işlem verilerinizi bir süre ölçüme göre (haftalık, aylık, üç aylık, yıllık) ayırır ve eski bölümleri ETL üzerinden raporlama / geçmiş veri deponuza taşırsınız. Yıldız şeması ve boyutları olan bir veri ambarı olabilir veya olmayabilir. Geçici sorgular yapmak için düzenli aralıklarla raporlar oluşturmak üzere toplu iş ve toplama işleri yapmak için veri depolama raporlama araçlarını kullanırsınız.

İşlemsel veri deponuzla ilgili raporlama yapmanızı önermem.

Basmayı tercih ederseniz, işte daha fazla düşünce:

1. "En iyisi" özneldir ve işe yarar.
2. Raporlama ürünü kendim yazmak yerine satın alırdım.
3. İlişkisel bir veritabanı kullanıyorsanız, SQL şehirdeki tek oyundur.
4. Saklı yordamlar, bunları yazma becerisine sahip olup olmadığınıza bağlıdır.

Evde kullandığınız proje yönetimi yazılımı? İnşa etmeden önce alırdım. Ralli ve Microsoft Project gibi bir şey.

Öncelikle bazı terminoloji, görev tarafı dediğiniz şey İşlemsel ve Raporlama tarafı Analytics'tir.

Harika bir yaklaşım olan CQRS'den zaten bahsettiniz ama yaklaşımın belgelenmiş pratik uygulaması çok az.

Yoğun bir şekilde test edilmiş olan, İşlemsel işlemlerinizi bir Analitik işlem motoru ile desteklemektir. Buna bazen Veri Depolama veya Veri Küpleri denir. Analitik ile ilgili en büyük sorun, işlem verilerinize yönelik sorguları gerçek zamanlı olarak çalıştırmaya çalışmak en iyi ihtimalle verimsiz olmasıdır çünkü okuma veya yazma için bir veritabanını optimize etmek gerçekten mümkün. İşlemlerde, işlem yapma / işlemlerde gecikmeleri önlemek için yüksek yazma hızları istiyorsunuz. Raporlama için, yüksek okuma hızları istiyorsunuz, böylece kararlar verilebiliyor.

Bu konular nasıl hesaba katılır? Anlamak için en basit yaklaşım, raporlama için düzleştirilmiş bir şema kullanmak ve verileri normalize edilmiş işlem şemasından denormalize analitik şemaya yönlendirmek için ETL (dönüşüm yükünü ayıklamak) kullanmaktır. ETL düzenli olarak bir temsilci aracılığıyla gerçekleştirilir ve analitik tablosunu önceden yükler, böylece raporlama motorunuzdan hızlı bir şekilde okunmaya hazır olur.

Veri depolamayı hızlandırmak için harika bir kitap, Ralph Kimball'ın Veri Ambarı Araç Setidir. Yaklaşan daha fazla el için. SQL Server'ın denemesini indirin ve ilk kitabın genel tartışmasını yapan, ancak SQL Server kullanarak kavramları nasıl uygulayacağınızı gösteren Microsoft Data Warehouse araç setini alın .

Bu sayfalardan ETL, Star Schema Design, BI, Dashboardlar ve diğer konular hakkında daha fazla ayrıntıya girmenize yardımcı olacak birkaç bağlantı vardır.

Nerede olursanız olun istediğiniz yere ulaşmanın en hızlı yolu, bir BI Uzmanı işe almak ve ihtiyacınız olanı uygularken onu gölgelemektir.

Peki ya raporlama tarafı? Veri ambarları kabul edilebilir mi, yoksa veritabanında iş mantığını ve verinin kendisini içerdikleri için kötü tasarım mı?

İş mantığından bahsettiğinizi sanmıyorum, bu daha çok raporlama mantığı. Kullanıcılar bu ekrandaki bilgilerle ne yaparlar, sadece durum güncellemeleri için midir? Etki alanı modeliniz işlem işlemlerini modellemek için kullanılır, raporlama farklı bir husustur. Verileri SQL Server'dan çekmek veya bir veri ambarına koymak, senaryoları bildirmek için iyidir.

Etki alanı modeliniz, proje üyesi gibi etki alanınızın değişmeyenlerini aynı anda aynı proje için ayıramaz veya yalnızca haftada x saat sayısını kaldırabilir. Ya da bu projeye, vb. Tamamlandığı için rezervasyon yapamazsınız, vb. Etki alanı modelinizin durumu (veri) raporlama için ayrı olarak kopyalanabilir.

Sorgu performansını iyileştirmek için maddi bir görünüm kullanabilirsiniz. Modelinize karşı bir işlem yapıldığında (örneğin, bu kişilerin 4 saatini x projesine ayırma zamanı geldiğinde) ve başarılı olduğunda raporlama veritabanında saklayabileceğiniz ve raporunuz için gerekli hesaplamaları yapabileceğiniz bir etkinlik oluşturabilir. Daha sonra üzerinde sorgulamak için çok hızlı olacaktır.

İşleminizi ve raporlama bağlamlarınızı ayrı tutun; etki alanı modelinin olmadığını bildirmek için ilişkisel bir veritabanı oluşturuldu.

DÜZENLE

Konuyla ilgili faydalı blog yazısı http://se-thinking.blogspot.se/2012/08/how-to-handle-reporting-with-domain.html

4 yıl sonra ve ben sadece bu soruyu tekrar buldum ve cevabım ne ise bende var.

Uygulamanıza ve özel gereksinimlerine bağlı olarak, etki alanı / işlem veritabanınız ve raporlamanız ayrı "sistemler" veya "motorlar" olabilir veya tek bir sistem tarafından sunulabilir. Bununla birlikte, mantıksal olarak ayrı olmaları gerekir - bu, kullanıcı arayüzüne veri almak ve sağlamak için farklı araçlar kullandıkları anlamına gelir.

Fiziksel olarak ayrı olmalarını (mantıksal olarak ayrı olmalarına ek olarak) tercih ederim, ancak bir çok kez onları birlikte başlatırsınız (fiziksel olarak) ve uygulama olgunlaştıkça onları ayırırsınız.

Her iki durumda da, yine, mantıksal olarak farklı olmalıdır. Raporlama sisteminde iş mantığını çoğaltmak sorun değil. Önemli olan, raporlama sisteminin etki alanı sistemi ile aynı cevaba ulaşmasıdır - ancak şansı farklı yollardan oraya ulaşmasıdır. Örneğin, etki alanı sisteminizde prosedür kodunda (muhtemelen) uygulanan bir çok sıkı iş kuralı vardır. Raporlama sistemi verileri okuduğunda aynı kuralları uygulayabilir ancak bunu SET tabanlı kod (örn. SQL) yoluyla da yapabilir.

İşte uygulamanızın mimarisinin bir evriminin, geliştikçe gerçekçi bir şekilde nasıl göründüğü:

Seviye 1 - Mantıksal olarak ayrılmış etki alanı ve raporlama sistemleri, ancak yine de aynı kod tabanında ve veritabanında

Seviye 2 - Mantıksal olarak ayrılmış etki alanı ve raporlama sistemleri, ancak şimdi senkronizasyon ile veritabanlarını ayırın.

Seviye 3 - Mantıksal ve Fiziksel Olarak Ayrılmış etki alanı ve raporlama sistemleri ve senkronizasyon ile veritabanlarını ayırın.

Ana fikir, raporlamanın ve etki alanının radikal biçimde farklı ihtiyaçlara sahip olmasıdır. Farklı veri profilleri (okuma ve yazma sıklığını okur), farklı performans gereksinimleri vb. Farklıdır. Bu yüzden farklı şekilde uygulanması gerekir ve bu da iş mantığının bir çoğaltılmasını gerektirir.

Etki alanı ve raporlama sistemlerinin iş mantığını ve birbirlerini güncel tutmanın bir yolunu bulmak sizin işinize kalmış.

Aktif projelerin listesini göstermek için rapor / gösterge tablosu gereklidir

Her projenin durumu , veritabanında statik, hesaplanmış ve iyi biçimlendirilmiş bilgiler olarak depolanmalı ve tüm simülasyonlar istemcide WebApp olarak ele alınmalıdır.

mevcut yanma oranında bütçe tükenme tarihi

bu tür bir projeksiyon talep üzerine çalıştırılmamalıdır. Yönetme bu istek üzerine bilgiler gibi geniş bir kullanım ile sonuçlanacaktır, vb kaynaklar, oran, görevler, kilometre taşları, üzerinde hesaplamalar hesaplama tabakasının gelecek çağrılar için bu sonuçların herhangi yeniden kullanmadan.

Dağıtılmış bir ortam ( özel veya genel bulut ) hayal ederek , hesaplama katmanında, düşük veritabanı kullanımında ve toplam önbellek eksikliğinde muazzam maliyetler elde edersiniz.

Bu önce etki alanı üzerinden mi yürütülmeli? Peki ya performans?

Yazılımınızın tasarımı, okuma sırasında değil, "veri girişi" sırasında gerekli sonucu elde etmek için gerekli hesaplamaların normalizasyonunu gerçekleştirme özelliğini içermelidir. Bu yaklaşım bilgisayar kaynaklarının kullanımını büyük ölçüde azaltır ve her şeyden önce müşteri tarafından "salt okunur" olarak kabul edilebilecek tablolar oluşturur. Bu, sağlam ve basit bir önbellekleme mekanizması oluşturmak için ilk adımdır.

Bu yüzden ilk önce bir arama, yazılım mimarisini tamamlamadan önce, Dağıtılmış Önbellek Sistemi olabilir .

(istek: toplama)! = 1: 1

Bu nedenle benim düşüncem (hem birinci hem de ikinci örnek için), verileri müşteri isteğine göre toplamayı azaltma hedefi olarak normalize etmenin ne zaman uygun olduğunu anlamaya çalışmak. Bir hedef sürdürülebilir bir sistem elde etmek ise hangisi 1: 1 olamaz (istek: toplama).

Hesaplamayı müşteriye dağıtın

Başka bir soru, yazılımın tasarımını bitirmeden önce, müşterinin tarayıcısını ne kadar normalleştirme yapmak istediğimiz olabilir.

MV * olarak adlandırıldı , bugün moda olduğu doğru, bunun yanı sıra, amaçlarından biri, birçok karmaşık uygulamanın (ve neyse ki faturalar için) mevcut olduğu düşünülebilecek WebApp (tek sayfa uygulaması) oluşturmaktır. bulut sağlayıcısına ödeme yaparız, bunlar müşteride yürütülür).

Sonuç olarak bu:

1. Verilerin sunumunu gerçekleştirmek için kaç işlemin gerçekten gerekli olduğunu anlamak;

2. Bunların ne kadarının arka planda yapılabileceğini analiz edin (ve normalize edildikten sonra önbellek sistemi aracılığıyla dağıtılır);

3. İstemcide kaç işlem gerçekleştirilebileceğini anlamak, projelerin yapılandırmasını almak, Web Uygulamasında Görünümler üzerinde çalıştırmak ve böylece arka uçta yapılan hesaplamayı azaltmak;

Sorgu için önbellek kullanın, önbellek için etki alanı kullanın.

Stackoverflow'ta "en iyi kullanıcılar" adı verilen bir özellik var. En üstteki kullanıcılar sayfasının altında bir satır bulabilirsiniz, "Sadece topluluk-wiki olmayan sorular ve cevaplar bu toplamlara dahil edilir ( günlük olarak güncellenmektedir )". Bu, verilerin önbelleğe alındığını gösterir.

Ama neden?

Belki performans sorunu için. Belki de sızıntı yapan etki alanı mantığıyla aynı endişeleri vardır ("bu durumda sadece topluluk-wiki olmayan sorular ve cevaplar bu toplamlara dahil edilmiştir").

Nasıl?

Bunu nasıl yaptıklarını gerçekten bilmiyorum, bu yüzden burada bir tahmin :)

İlk önce hedef soru / cevapları bulmamız gerekiyor. Bir zamanlama görevi işe yarayabilir, tüm potansiyel hedefleri getirebilir.

İkincisi, sadece bir soruya / cevaba bakalım. Topluluk olmayan bir wiki mi? 30 gün içinde mi? Etki alanı modelleriyle yanıtlamak oldukça kolaydır. Oyları sayın ve memnun kalırsanız önbellekleyin.

Şimdi önbelleğe sahibiz, bunlar alan türevlerinin çıktısı. Sorgu hızlı ve kolaydır çünkü uygulanacak basit kriterler vardır.

Sonuçların daha "gerçek zamanlı" olması gerekiyorsa ne olur?

Olaylar yardımı yapabilir. Önbelleğe alma işlemini zamanlama göreviyle tetiklemek yerine, işlemi birçok alt işleme ayırabiliriz. Örneğin, birileri su aygırı'nın cevabına oy verdiğinde, su aygırı'nın en üst düzey kullanıcıları önbelleğinin güncellemesini tetikleyen bir etkinlik yayınlarız. Bu durumda, sık sık hızlı küçük görevler görebiliriz.

CQRS gerekli mi?

Ne zamanlama görev yaklaşımı ne de olay yaklaşımı ile. Ancak cqrs'ın bir avantajı var. Önbellek genellikle yüksek oranda görüntülenmeye yöneliktir, ilk başta bazı öğeler gerekmiyorsa, bunları hesaplayıp önbelleklemeyebiliriz. Olay kaynağı olan CQRS, olayları yeniden çalarak geçmiş veriler için önbelleğin yeniden oluşturulmasına yardımcı olur.

Bazı ilgili sorular:
1. https://stackoverflow.com/questions/21152958/how-to-handle-summary-report-in-cqrs 2. https://stackoverflow.com/questions/19414951/how-to-use zeng-alan-ile-masif-operasyonlarında / 19416703 # 19416703

Umarım yardımcı olur :)

Yasal Uyarı:
Etki alanı modelleri olan uygulamalarda oldukça deneyimsizim.
Tüm kavramları anlıyorum ve uzun zamandır bu kavramları üzerinde çalıştığım uygulamalara nasıl uygulayacağımı düşünüyorum (ki bunlar ARE açısından zengin, ancak OO'dan yoksun, gerçek alan modelleri vs.) .
Bu soru benim de karşılaştığım kilit sorunlardan biri. Bunu nasıl çözeceğime dair bir fikrim var, ama daha önce de söylediğim gibi ... bu sadece ortaya çıktığım bir fikir.
Henüz gerçek bir projede uygulamadım, ancak çalışmaması için bir neden göremiyorum.

Şimdi bunu açıkça ortaya koydum, işte ortaya çıkan şey işte - İlk örneğinizi (proje ölçümleri) açıklamak için kullanacağım:

Birisi bir projeyi düzenlediğinde, yine de etki alanı modelinizle yükleyip kaydediyorsunuz.
Bu durumda, her ikinizin sahip tüm tüm ölçümleri hesaplamak için yüklenen bilgilerin (toplam bütçesi, tarih vs. için çaba) bu proje için.

Bunu etki alanı modelinde hesaplayabilir ve etki alanı modelinin geri kalanıyla veritabanına kaydedebilirsiniz.
Böylece Projectetki alanı modelinizdeki sınıf TotalBudget, EffortToDatevb. Gibi bazı özelliklere sahip olacak ve aynı zamanda etki alanı modelinizin depolandığı veritabanı tablolarında (aynı tablolarda veya ayrı bir tabloda ... isimleri var.) önemli değil) .

Tabii ki, başlangıçta mevcut olan tüm projelerin değerini hesaplamak için tek seferlik bir çalışma yapmanız gerekiyor. Ancak bundan sonra, bir etki alanı modeli ile bir proje düzenlendiğinde veriler otomatik olarak mevcut hesaplanan değerlerle güncellenir.

Herhangi bir rapora ihtiyaç duyduğunuzda, gerekli tüm veriler zaten oradadır (önceden hesaplanmıştır) ve şöyle bir şey yapabilirsiniz:

select ProjectName, TotalBudget, EffortToDate from Projects where TotalBudget > X

Verileri doğrudan etki alanı modelinin depolandığı tablolardan almanız veya bir şekilde verileri ikinci bir veritabanına, bir veri ambarına ya da her neyse çıkartmanız önemli değil:

1. Raporlama deponuz gerçek veri deponuzdan farklıysa, verileri yalnızca "etki alanı modeli tablolarından" kopyalayabilirsiniz.
2. Doğrudan gerçek veri deponuzu sorgularsanız, veriler zaten oradadır ve hiçbir şey hesaplamanıza gerek yoktur

Her iki durumda da, hesaplamalar için iş mantığı tam olarak bir yerdedir: etki alanı modeli.
Başka bir yere ihtiyacınız yok, bu yüzden çoğaltmanız gerekmez.