* Ekle / Oluştur komutları CQRS + Olay Kaynağı mimarisinde nasıl ele alınmalıdır?

İlk uygulamamı Olay Kaynağı ile birlikte CQRS kalıbını kullanarak uygulamak istiyorum. Agrega köklerinin oluşturulmasının nasıl düzgün bir şekilde ele alınması gerektiğini merak ediyorum. Birisinin CreateItem komutu gönderdiğini varsayalım. Nasıl ele alınmalı? ItemCreated etkinliği nerede saklanmalıdır? Yeni bir öğenin ilk etkinliği olarak? Yoksa tüm öğeleri bir araya getiren bir tür ItemList varlığı mı olmalı ve etkinlik listesi yalnızca ItemCreated olaylarından mı oluşuyor?

Udi Dahan , toplu kökler oluşturmamayı ve her zaman bunun yerine bir tür getirme yöntemi kullanmamayı önerir . Ama yeni ve kesinlikle herhangi bir kimliği atanmamış bir şeyi nasıl getirebilirim. Arkadaki fikri anlıyorum ve yeni bir nesnenin, durumu üzerinde sıfır olaydan oluşan bir nesne olduğunu düşünmek oldukça makul. Ama nasıl kullanmalıyım? Depomda farklı bir yöntem olmalı mı getNewItem()yoksa get(id)yöntemimi kabul etmeli Optional<ItemId>mi?

Düzenleme: Kazma bir süre sonra aktörler kullanarak yukarıda bahsedilen desenlerin gerçekten ilginç bir uygulama bulundu . Yazar, toplu oluşturmak yerine, yeni oluşturulan UUID ile bir tür depodan alır. Bu yaklaşımın dezavantajı, geçici bir tutarsızlık durumuna izin vermesidir. Ben de deleteböyle bir yaklaşımla yöntemi nasıl uygulayabileceğimi merak ediyorum . Toplamın etkinlik listesine Silinmiş etkinliği mi eklemeniz yeterlidir?

Udi'nin gönderisindeki fikir, topladığım gibi, ince havadan hiç bir şey görünmüyor. Öğenin oluşturulmasına neden olan (neredeyse) her zaman bir şey veya daha spesifik olarak bir alan adı işlemi vardır. Tıpkı Udi'nin siteye kaydolan bir ziyaretçiden doğan bir kullanıcı örneği gibi. Bu noktada ve bu sınırlı bağlamda Ziyaretçi IP adresi tarafından alınan toplam köküdür. Bu Ziyaretçi daha sonra, bu noktada bir kullanıcı olan yeni "öğe" yi, Kayıt adlı bir alan adı işlemi aracılığıyla oluşturur . Aynı şey önceki adım için de geçerlidir, bu da başka bir sınırlı bağlamdır: Yönlendiren, URL tarafından alınan ve ziyaretçinin doğduğu BroughtVisitorWithIp adlı bir alan adı işlemine sahip AR'dir .

Udi, silme konusunda da çok güzel yazıyor: http://www.udidahan.com/2009/09/01/dont-delete-just-dont/ . Ana fikir, hiçbir şeyi silmemenizdir. Arkada her zaman yakalamak istediğimiz bir alan adı işlemi vardır. Silinmek yerine iptal edilen bir sipariş gibi. Oku, çok iyi bir gönderi.

Her iki hesaptaki ana nokta, DDD ve özellikle Olay Sağlama yapmak, hiçbir zaman doğrudan CRUD işlemleri yapmamanızdır. Kendinizi gerçekten sadece bazı verileri eklemeniz, güncellemeniz veya silmeniz gereken bir durumda bulursanız ve bunun arkasında gerçekten bir etki alanı işlemi yoksa, belki DDD ve Olay Kaynaklandırma bu sınırlı bağlam için uygun değildir . Tek bir sınırlı bağlam bir ilkeye bağlı kaldığı sürece bu ikisini istediğiniz gibi birleştirebilirsiniz. Bu şekilde, CRUD stili sınırlı bağlam, veritabanında bir satır oluşturabilir; bu, artık AR'yi alabileceğiniz ve oluşturmak zorunda kalmayacağınız başka bir sınırlı bağlamda varlık ve Toplam kök haline gelir.