Bu durumda iki tür doğrulama ayırmanız gerektiğini düşünüyorum; etki alanı doğrulaması ve uygulama doğrulaması .
Uygulama doğrulama, 'text' komut özelliğinin 20 ile 200 karakter arasında olduğunu doğruladığınızda sahip olduğunuzdur; böylece bunu GUI ve POST sonrasında sunucuda da çalışan bir view-model-validator ile doğrularsınız. Aynı şey e-posta için de geçerlidir (btw, umarım `` 32.d + "Hello World .42" @ mindomän.local "gibi bir e-postanın RFC'ye göre geçerli olduğunu fark edersiniz).
Sonra başka bir doğrulama daha var; makalenin var olup olmadığını kontrol edin - GUI'den gönderilen ve ona yorum eklemekle ilgili bir komut varsa, makalenin neden var olmaması gerektiğini kendinize sormalısınız. GUI nihayetinde tutarlı mıydı ve veri deposundan fiziksel olarak silinebilecek toplam bir köke, makaleye sahipsiniz? Bu durumda, komut işleyicisi toplam kökü yükleyemediğinden, komutu yalnızca hata kuyruğuna taşırsınız.
Yukarıdaki durumda, zehir mesajlarını işleyen bir altyapıya sahip olacaksınız - örneğin mesajı 1-5 kez tekrar dener ve daha sonra mesajların toplanmasını manuel olarak inceleyebileceğiniz ve ilgili olanları yeniden gönderebileceğiniz bir poision kuyruğuna taşırlar. İzlemek iyi bir şey.
Şimdi tartıştık:
Alan adıyla senkronize olmayan komutlar ne olacak? Belki de alan mantığınızda, bir makaleye 5 yorum yapıldıktan sonra, sadece 400 karakterin altındaki yorumlara izin verildiğini, ancak bir adamın 5. yorumu ile çok geç olduğunu ve 6. olması gerektiğini söyleyen bir kuralınız var - GUI bunu yakalamadı çünkü komutunu gönderme noktasında alan adıyla tutarlı değildi; bu durumda alan adı mantığınızın bir parçası olarak bir 'doğrulama hatası' olur ve ilgili hata olayını döndürürsünüz.
Etkinlik, bir ileti aracısına veya özel dağıtım programınıza bir ileti biçiminde olabilir. Uygulama monolitikse, web sunucusu hem başarılı bir olayı hem de belirtilen başarısızlık olayını eşzamanlı olarak dinleyebilir ve uygun görünümü / kısmi görüntüleyebilir.
Çoğu zaman birçok komut türü için hata anlamına gelen özel bir etkinliğiniz vardır ve bu olay web sunucusunun bakış açısından abone olduğunuz olaydır.
Üzerinde çalıştığımız sistemde, bir MassTransit + RabbitMQ ileti yolu + aracısı üzerinden komutlar / olaylar ile istek yanıtı yapıyoruz ve bu belirli etki alanında (kısmen bir iş akışını modelleme) adlı bir etkinliğimiz var InvalidStateTransitionError. Durum grafiğindeki bir kenar boyunca hareket etmeye çalışan çoğu komut bu olayın gerçekleşmesine neden olabilir. Bizim durumumuzda, GUI'yi nihayetinde tutarlı bir paradigmadan sonra modelleyiyoruz ve bu nedenle kullanıcıyı 'komut kabul edildi' sayfasına gönderiyoruz ve daha sonra web sunucusunun görünümlerinin etkinlik abonelikleri yoluyla pasif olarak güncellenmesine izin veriyoruz. Ayrıca, toplam köklerde etkinlik kaynağı yaptığımız (ve ayrıca sagalar için de yapacağız) belirtilmelidir.
Gördüğünüz gibi, bahsettiğiniz doğrulamaların çoğu, gerçek alan mantığı değil, uygulama tipi doğrulamalardır. Etki alanınız basitse ancak DDD yapıyorsanız basit bir etki alanı modeline sahip olmanızda sorun yoktur. Ancak alan adınızı modellemeye devam ettikçe, alan adının ilk ortaya çıktığı kadar basit olmayabileceğini göreceksiniz. Çoğu durumda, toplu kök / varlık, bir komutun neden olduğu bir yöntem çağrısını kabul edebilir ve herhangi bir doğrulama bile gerçekleştirmeden durumunun bir kısmını değiştirebilir - özellikle de komutlarınıza web sunucusunda doğrularsanız yaptığınız gibi güveniyorsanız kontrol edersiniz.
DDD ile ilgili iki sunumu Norveç Geliştirici Konferansı 2011'den ve Greg'in Öredev 2010'daki sunumunu izlemeyi tavsiye edebilirim .
Şerefe, Henke