Olay tedarikinde süreç yöneticisi nasıl uygulanır?

Ben CQRS ve olay kaynak kavramlarını öğrenmek için küçük bir örnek uygulama üzerinde çalışıyorum. Bir Baskettopluluğum veProductBağımsız olarak çalışması toplama var.

Uygulamayı göstermek için bazı sahte kodlar

Basket { BasketId; OrderLines; Address; }

// basket events
BasketCreated { BasketId; }
ItemAdded { BasketId; ProductId; Quantity }
AddItemSucceeded { BasketId; ProductId; Quantity }
AddItemRevoked { BasketId; ProductId; Quantity }
ItemRemoved { BasketId; ProductId; Quantity }
CheckedOut { BasketId; Address }

Product { ProductId; Name; Price; }

// product events
ProductReserved { ProductId; Quantity }
ProductReservationFailed { ProductId; Quantity }
ProductReservationCancelled { ProductId; Quantity; }

Komutlar, zorunlu adı kullanarak ve geçmiş zamanı değil, olaylara oldukça benzer.

Şu anda bunlar bağımsız olarak iyi çalışıyor. Bir komut AddItemyayınlıyorum ItemAddedveBasket toplamada 'Sepet' durumu ile ne yapması gerektiğini yapan . Benzer şekilde, ürün için komut ve olaylar iyi çalışır.

Şimdi bunu (böyle komutlar ve olaylar açısından) böyle bir şey olacak bir süreçte birleştirmek istiyorum:

İşlem yöneticisi aşağıdakileri yapar:

on BasketCreated: CreateShoppingProcess
on ItemAdded: ReserveProduct
on ProductReserved: SucceedAddingItem // does nothing, but needs to be there so that the basket knows it can check out
on ProductReservationFailed: RevokeAddItem
on RemoveItem: CancelProductReservation
on Checkout: CreateOrder // create an order and so on...

Kesin cevapları bulamadığım sorular:

1. Süreç yöneticisine devam etmem gerekiyor mu? Benim yaptığım gibi görünüyor, ama emin değilim
2. Eğer yaparsam, süreç yöneticisi için olayları kaydetmem gerekir. Ancak, Dinlediği olaylar toplanmalara bağlıdır. İşlem kimliğini bunlara ekleyebilir miyim? Yalnızca işlem yöneticisi için ayrı etkinliklerim var mı? Bunu yapmak ve mümkün olduğunca KURU tutmak
3. ProductReservedEtkinliklerin hangi sepet için olduğunu nasıl bilebilirim ? Bunlara da sahip olmak uygun mudur BasketIdyoksa sızan bilgi midir?
4. Etkinlikler arasında nasıl ilişki kurabilirim, hangisinin ItemAddedhangi ProductReservedetkinliği ürettiğini nasıl bilebilirim ? Ben birEventId mı ? Bu tuhaf görünüyor ...
5. BasketBasit bir toplu işlem yerine işlem yöneticisi olarak mı uygulamalıyım ?

Biraz daha araştırma yaptıktan sonra buna geldim: Saga, kendi olaylarını koruyan ve dışarıdan gelen olayları dinleyen bir şey. Temel olarak, kendi küçük dünyasının dışında gerçekleşen olaylara da tepki verebilen bir Agrega.

İşlem Yöneticisi dışarıdan gelen olaylarla çalışır ve komutlar gönderir. Tarihi, korrelationId gibi ortak bir tanımlayıcıyı paylaşan Agregalarda meydana gelen olaylardan yeniden oluşturulabilir.

Rinat Abdullin'in gelişen iş süreci hakkında yazdıklarını gözden geçirin . Özellikle, hızlı değişen bir ortamda bir iş süreci geliştirme tavsiyesine dikkat edin - bir süreç yöneticisi ekrana bakan bir insan için otomatik bir yedek "sadece" dir.

Bir süreç yöneticisinin kendi zihinsel modelim, bekleyen komutların bir listesini sorgulayabileceğiniz olay kaynaklı bir projeksiyon olmasıdır.

Süreç yöneticisine devam etmem gerekiyor mu? Benim yaptığım gibi görünüyor, ama emin değilim

Bu bir okuma modeli. Her ihtiyacınız olduğunda süreç yöneticisini olayların geçmişinden yeniden oluşturabilirsiniz; veya güncellediğiniz bir anlık görüntü gibi ele alabilirsiniz.

Eğer yaparsam, süreç yöneticisi için olayları kaydetmem gerekir.

Hayır - süreç yöneticisi bir yöneticidir . Kendi başına yararlı bir şey yapmaz; bunun yerine toplamalara çalışma yapmalarını söyler (yani, kayıt defterinde değişiklik yapma).

ProductReserved olaylarının hangi sepet için olduğunu nasıl bilebilirim? Bunlarda BasketId bulundurmak uygun mu yoksa sızan bilgi mi

Elbette. Not: Çoğu "gerçek" alışveriş alanında, bir siparişi işlemeden önce envanter ayırmak konusunda ısrarcı olmazsınız; işletmeye gereksiz çekişme katıyor. İşletmenizin siparişi kabul etmesi ve daha sonra nadiren de olsa siparişin gerekli zamanda yerine getirilememesi durumunda özür dilemesi olasıdır.

Etkinlikler arasında nasıl ilişki kurabilirim, hangi Item Added'nin hangi ProductReserved etkinliğini ürettiğini nasıl bilebilirim?

İletilerin meta verileri vardır - özellikle, bir causationIdentifier (böylece hangi olayların hangi olayları ürettiğini tanımlayabilirsiniz) ve bir korelasyon genel olarak konuşmayı izlemek için ekleyebilirsiniz.

Örneğin, işlem yöneticisi komutta korelasyon kimliği olarak kendi kimliğini yazar; bir kopya tarafından üretilen olaylar komutun korelasyon kimliğini kopyalar ve süreç yöneticiniz kendi korelasyonKimliği olan tüm olaylara abone olur.

Sepeti basit bir toplu işlem yerine işlem yöneticisi olarak mı uygulamalıyım?

Benim tavsiyem hayır. Ancak Udi Dahan'ın gözden geçirmeniz gereken farklı bir görüşü var; yani CQRS sadece agregalarınız destansa mantıklıdır - Udi süreç yöneticisinin baskın yazım olduğu yerde destan kullandı.

süreç yöneticileri toplamları almalı mı?

Pek sayılmaz? Süreç yöneticileri alan adı durumu ile değil, öncelikle düzenleme ile ilgilenir. Bir sürecin bir örneği, gözlemledikleri tüm olayların bir tarihi biçiminde "duruma" sahip olacaktır - Z olayına yanıt olarak yapılacak doğru şey X ve Y olaylarını görüp görmediğimize bağlıdır. Bu nedenle, bu durumun bir temsilini saklamanız ve yüklemeniz gerekebilir (bu düz bir şey olabilir veya gözlenen olayların geçmişi olabilir).

(Çünkü "gerçekten" demek agrega belli belirsiz yeterince gözlenen olayların bu liste iddia tamamen yanlış olmadığını tanımlanır olan bir "agrega" farklılıklar uygulamaya konmasından daha anlamsal vardır -. Biz yük süreç durumunu ve sonra ne mesajlar karar sistemin etki alanından sorumlu kısımlarına gönderin . Burada biraz el sallama oluyor.)

PM'nin bir tür devlet yönetimini diğeri üzerinde kullanmasına gerek yoktur, çünkü sadece bir şeyleri canlı olarak yapmaktan ve tekrarlar sırasında asla yapmaktan sorumlu mudur?

Pek değil - devlet yönetimi bir işveren değil, aynı zamanda bir izci. Süreç yöneticisinin herhangi bir sinyal yaymaması gerektiği durumlarda, ona dünyaya inert bağlantılar verirsiniz. Başka bir deyişle, dispatch(command)hayır-op.

Aradığın şey aslında bir süreç yöneticisi olan "Saga" adlı bir desene sahip.

Destanlar uzun süreli işlemler için de mükemmeldir, çünkü ilişkili komutlar arasındaki durumu koruyabilir.

İşte Sagas hakkında harika bir makale