İki hafta önce etkinliklerin tedarikine giriş olarak bir blog yazısı yazdım. Birçoğunun konusu büyük ilgi gördü, birçok geri bildirim vardı ve elbette birkaç soru da vardı. Bugünün blog yazısında bu soruların çoğunu alıp cevaplıyorum. Her şeyden önce, olayların tedarikiyle ilgili bir kavrama daha fazla giriş yapıyorsunuz: Bugün aynı zamanda CQRS adı verilen bir mimari modeli. Çalışma şekli, uygulamaların ne olduğu, onu olayların tedariki ile nasıl birleştirebileceğiniz vb.
Duyuru
Golo Roden, yerel web GmbH'nin kurucusu ve CTO'sudur. Olaylara ve hizmetlere dayalı olarak dağıtılmış mimarilere özellikle dikkat ederek web ve bulut uygulamalarının ve arıların anlayışı ve geliştirilmesi ile ilgilidir. Yol gösterici ilkesi, yazılımın gelişiminin kendi başına bir son olmaması, ancak her zaman aşağıda bir profesyonellik izlemesi gerektiğidir.
Olay tedariki olan veya olmayan CQR'ler?
Çok kısaca başlayalım, bir açıklama ile başlayalım: Belki CQRS'yi duymuşsunuzdur ve şimdi tam olarak ne olduğunu bilmek istersiniz, ancak belki iki hafta önce etkinliklerin tedariki hakkındaki blog yayınını okumadınız. Şimdi soru ortaya çıkıyor: Bugünün yazısını hala “adil” okuyabilir misiniz yoksa ilk olarak olay arzı konusuyla mı karşılaşmalısınız?
Bu çok önemlidir: CQR'ler ve olayların arzı bağımsız olarak var olan iki kavramdır. Bu, CQR'leri etkinlik arzını kullanmak zorunda kalmadan uygulamanın mümkün olduğu ve CQR'leri kullanmak zorunda kalmadan etkinlik tedarikini de uygulayabileceğiniz anlamına gelir ve bu konuda bu blog yayınını kendinden üretilen bir konu olarak da görebilirsiniz. .
Ancak: İki kavram çok iyi tamamlandı. Bu bağlamda, onları nadiren pratikte bulacaklar, ama genellikle birlikte. Bu yüzden bugün bu blog yazısında iki hafta önce yazdıklarımı ödüyorum. Bu blog gönderisini henüz görmediyseniz, şimdi telafi etmenizi tavsiye ederim. Alternatif olarak, bunu bir video olarak da görebilirsiniz.
CQRS nedir?
Ama yine de CQRS nedir? Kısaltma, “Komut Sorgusu için Sorumluluk Ayrılımı” veya komutlar ve sorular için sorumlulukların ayrılması anlamına gelir.
Aslında, başlangıçta göründüğünden çok daha kolay. CQRS'nin ana fikri, uygulamalara erişim için yalnızca iki tür etkileşim modelinin olmasıdır: ya kullanıcı, sistemde bir şeyi değiştirmek amacıyla bir eylem gerçekleştirir, ya bir şey bilmek ister. Artık seçenek yok. Bu, bunu ya da sizin için yapmanız gereken bir yazılımı paylaştığınız anlamına gelir, bu yüzden bir komut verin (bu bir “komut “dur”) veya bir soru için bilgi sağlamak veya bir bilgi vermek için bilgi yazılımına sorun Sorgu (ve bu bir “sorgu” adlı bir “sorgu”).
Önerilen editoryal içerik
Rızanızla, burada harici bir YouTube videosu (Google Ireland Limited) burada davet edilir.
YouTube videosu her zaman yüklenir
YouTube videosu artık yüklüyor
CQRS – İhtiyacınız olan tek video // Almanca
Biri, yani bir komut, genellikle bir değişiklik çizer ve bu nedenle bir yazma süreci, diğeri veya bir sorgu, yalnızca okumaya erişir. Böylece şunu da söyleyebilirsiniz: Yazma ve okumaya erişim vardır. CQRS tasarım modeli artık uygulamanızı ikiye kullanmanız gerektiğini söylüyor: kısmen yazma süreçleriyle ilgilenen ve başka bir kısımda okuma süreçleriyle ilgilenen. Bu yüzden yapmalılar ve bu tam olarak okuma için yazma sorumluluğunu ayıran orijinal ifademdi.
Bu tasarım modelinin söylediği şey, bu ayrımın ne tür bir yapacağıdır. Bu nedenle, bu sadece yazma ve okuma arıları rotaları arasında zihinsel olarak ayrılmak anlamına gelirse veya iki ayrı arı inşa ederseniz veya iki ayrı hizmet veya başka bir şey olup olmadığı anlamına gelir. İngilizce'de olduğu gibi, bu “yorumun yüksekliğinde”. Ancak, daha sonra daha ayrıntılı olarak konuşmaya geliyoruz.
Neden hepsi?
İlk soru: Neden yapmalısınız? Peki bu öneri neden CQRS modeli şeklinde?
Arkasında çok basit bir husus var ve arılarla çok az ilgisi var, ancak veritabanlarıyla çok daha fazlası var: Klasik mimari hakkında konuştuğumuzda, genellikle bir kullanıcı arayüzümüz var, bir şekilde bir tür arı ve sonunda veritabanı. Veritabanı tam anlamıyla geliştirme merkezinde olmasa da, genellikle yazılımın geliştirilmesinde ayrıntılı olarak karşılaşırız ve genellikle veritabanında seçilen veri modelinin API'da şirket mantığının nasıl oluşturulduğu üzerinde önemli etkileri vardır. Bu, önemli bir sorunun şu anlamına gelir: İyi bir veri modeli nedir?
Akademik dünyanın uygun bir yanıtı vardır: Veritabanı teorisinde farklı normal formlar vardır. Biraz veri modellerinin nasıl tasarlanacağına dair kuralların bir cümlesine benzediğini hayal edebilirsiniz. Özellikle, bunların beş farklı varyasyonu vardır ve beşinci normal form Kutsal Kâse'ye biraz karşılık gelir: eğer uygularsanız, her şeyin çok temiz ve iyi yapılandırılmış olması, hiçbir bilginin kopyalanmadığı, bunun verilerde fazlalık değil vb. Bu arzu edilir çünkü bu nedenle çok kolay uygulanabilir. Bu bakış açısından, beşinci normal form veri yazma konusunda bir rüyadır.
Işık olduğu yerde de gölge
Verileri tekrar okumanız biraz mutsuz. Bu, beşinci normal şekilde açıkça mümkündür, sadece genellikle çok karmaşık bir sorgu yapmanız gerekir ve bu nedenle, örneğin bir kullanıcının ana verileri gibi basit bir şey okumak için aniden 27 bir araya gelir. Bu, okumanın oldukça uygun olduğu anlamına gelir, ancak tamamen verimsiz ve yavaştır. Tabii ki, bu çok az pratiktir ve günlük yaşamda çok yararlı değildir. Kısacası: Beşinci Normal şekil yazma için uygundur, ancak okuma felaketi.
Diğer uç ilk normal şekil olacaktır: İşte kullanıcı arayüzünde bulunan her görünüm için uygun bir tablo ve veriler ihtiyacınız olan yere dağıtılır. Bu, verilerin tamamen gösterildiği anlamına gelir, bu da hızlı bir şekilde okumayı sağlar: çünkü birden fazla SELECT * FROM xy Genellikle gerekli değildir, sonuçta, tanım gereği her görünüm için uygun bir tablo vardır. Bu bağlamda, verileri okumak söz konusu olduğunda ilk normal form bir rüyadır.
Bununla birlikte, bu durumda yazmak oldukça zordur, çünkü aynı bilgileri birkaç kez koymanız gerekir, birkaç kez saklamanız gerekir ve bu nedenle tutarlılığı ve bütünlüğü korumak çok karmaşıktır. Bu yüzden ilk normal formun beşincinin tam tersi olduğunu söyleyebilirsiniz: birincisi okumak iyidir, ancak yazmak kötüdür.
Duyuru
Golo Roden, yerel web GmbH'nin kurucusu ve CTO'sudur. Olaylara ve hizmetlere dayalı olarak dağıtılmış mimarilere özellikle dikkat ederek web ve bulut uygulamalarının ve arıların anlayışı ve geliştirilmesi ile ilgilidir. Yol gösterici ilkesi, yazılımın gelişiminin kendi başına bir son olmaması, ancak her zaman aşağıda bir profesyonellik izlemesi gerektiğidir.
Olay tedariki olan veya olmayan CQR'ler?
Çok kısaca başlayalım, bir açıklama ile başlayalım: Belki CQRS'yi duymuşsunuzdur ve şimdi tam olarak ne olduğunu bilmek istersiniz, ancak belki iki hafta önce etkinliklerin tedariki hakkındaki blog yayınını okumadınız. Şimdi soru ortaya çıkıyor: Bugünün yazısını hala “adil” okuyabilir misiniz yoksa ilk olarak olay arzı konusuyla mı karşılaşmalısınız?
Bu çok önemlidir: CQR'ler ve olayların arzı bağımsız olarak var olan iki kavramdır. Bu, CQR'leri etkinlik arzını kullanmak zorunda kalmadan uygulamanın mümkün olduğu ve CQR'leri kullanmak zorunda kalmadan etkinlik tedarikini de uygulayabileceğiniz anlamına gelir ve bu konuda bu blog yayınını kendinden üretilen bir konu olarak da görebilirsiniz. .
Ancak: İki kavram çok iyi tamamlandı. Bu bağlamda, onları nadiren pratikte bulacaklar, ama genellikle birlikte. Bu yüzden bugün bu blog yazısında iki hafta önce yazdıklarımı ödüyorum. Bu blog gönderisini henüz görmediyseniz, şimdi telafi etmenizi tavsiye ederim. Alternatif olarak, bunu bir video olarak da görebilirsiniz.
CQRS nedir?
Ama yine de CQRS nedir? Kısaltma, “Komut Sorgusu için Sorumluluk Ayrılımı” veya komutlar ve sorular için sorumlulukların ayrılması anlamına gelir.
Aslında, başlangıçta göründüğünden çok daha kolay. CQRS'nin ana fikri, uygulamalara erişim için yalnızca iki tür etkileşim modelinin olmasıdır: ya kullanıcı, sistemde bir şeyi değiştirmek amacıyla bir eylem gerçekleştirir, ya bir şey bilmek ister. Artık seçenek yok. Bu, bunu ya da sizin için yapmanız gereken bir yazılımı paylaştığınız anlamına gelir, bu yüzden bir komut verin (bu bir “komut “dur”) veya bir soru için bilgi sağlamak veya bir bilgi vermek için bilgi yazılımına sorun Sorgu (ve bu bir “sorgu” adlı bir “sorgu”).
Önerilen editoryal içerik
Rızanızla, burada harici bir YouTube videosu (Google Ireland Limited) burada davet edilir.
YouTube videosu her zaman yüklenir
YouTube videosu artık yüklüyor
CQRS – İhtiyacınız olan tek video // Almanca
Biri, yani bir komut, genellikle bir değişiklik çizer ve bu nedenle bir yazma süreci, diğeri veya bir sorgu, yalnızca okumaya erişir. Böylece şunu da söyleyebilirsiniz: Yazma ve okumaya erişim vardır. CQRS tasarım modeli artık uygulamanızı ikiye kullanmanız gerektiğini söylüyor: kısmen yazma süreçleriyle ilgilenen ve başka bir kısımda okuma süreçleriyle ilgilenen. Bu yüzden yapmalılar ve bu tam olarak okuma için yazma sorumluluğunu ayıran orijinal ifademdi.
Bu tasarım modelinin söylediği şey, bu ayrımın ne tür bir yapacağıdır. Bu nedenle, bu sadece yazma ve okuma arıları rotaları arasında zihinsel olarak ayrılmak anlamına gelirse veya iki ayrı arı inşa ederseniz veya iki ayrı hizmet veya başka bir şey olup olmadığı anlamına gelir. İngilizce'de olduğu gibi, bu “yorumun yüksekliğinde”. Ancak, daha sonra daha ayrıntılı olarak konuşmaya geliyoruz.
Neden hepsi?
İlk soru: Neden yapmalısınız? Peki bu öneri neden CQRS modeli şeklinde?
Arkasında çok basit bir husus var ve arılarla çok az ilgisi var, ancak veritabanlarıyla çok daha fazlası var: Klasik mimari hakkında konuştuğumuzda, genellikle bir kullanıcı arayüzümüz var, bir şekilde bir tür arı ve sonunda veritabanı. Veritabanı tam anlamıyla geliştirme merkezinde olmasa da, genellikle yazılımın geliştirilmesinde ayrıntılı olarak karşılaşırız ve genellikle veritabanında seçilen veri modelinin API'da şirket mantığının nasıl oluşturulduğu üzerinde önemli etkileri vardır. Bu, önemli bir sorunun şu anlamına gelir: İyi bir veri modeli nedir?
Akademik dünyanın uygun bir yanıtı vardır: Veritabanı teorisinde farklı normal formlar vardır. Biraz veri modellerinin nasıl tasarlanacağına dair kuralların bir cümlesine benzediğini hayal edebilirsiniz. Özellikle, bunların beş farklı varyasyonu vardır ve beşinci normal form Kutsal Kâse'ye biraz karşılık gelir: eğer uygularsanız, her şeyin çok temiz ve iyi yapılandırılmış olması, hiçbir bilginin kopyalanmadığı, bunun verilerde fazlalık değil vb. Bu arzu edilir çünkü bu nedenle çok kolay uygulanabilir. Bu bakış açısından, beşinci normal form veri yazma konusunda bir rüyadır.
Işık olduğu yerde de gölge
Verileri tekrar okumanız biraz mutsuz. Bu, beşinci normal şekilde açıkça mümkündür, sadece genellikle çok karmaşık bir sorgu yapmanız gerekir ve bu nedenle, örneğin bir kullanıcının ana verileri gibi basit bir şey okumak için aniden 27 bir araya gelir. Bu, okumanın oldukça uygun olduğu anlamına gelir, ancak tamamen verimsiz ve yavaştır. Tabii ki, bu çok az pratiktir ve günlük yaşamda çok yararlı değildir. Kısacası: Beşinci Normal şekil yazma için uygundur, ancak okuma felaketi.
Diğer uç ilk normal şekil olacaktır: İşte kullanıcı arayüzünde bulunan her görünüm için uygun bir tablo ve veriler ihtiyacınız olan yere dağıtılır. Bu, verilerin tamamen gösterildiği anlamına gelir, bu da hızlı bir şekilde okumayı sağlar: çünkü birden fazla SELECT * FROM xy Genellikle gerekli değildir, sonuçta, tanım gereği her görünüm için uygun bir tablo vardır. Bu bağlamda, verileri okumak söz konusu olduğunda ilk normal form bir rüyadır.
Bununla birlikte, bu durumda yazmak oldukça zordur, çünkü aynı bilgileri birkaç kez koymanız gerekir, birkaç kez saklamanız gerekir ve bu nedenle tutarlılığı ve bütünlüğü korumak çok karmaşıktır. Bu yüzden ilk normal formun beşincinin tam tersi olduğunu söyleyebilirsiniz: birincisi okumak iyidir, ancak yazmak kötüdür.