DDD'yi uygulama: kullanıcılar ve izinler

Etki alanı odaklı tasarım ilkelerini kavramaya çalışan küçük bir uygulama üzerinde çalışıyorum. Başarılı olursa, bu daha büyük bir proje için bir pilot olabilir. "Etki Alanına Dayalı Tasarımın Uygulanması" (Vaughn Vernon tarafından) kitabını takip etmeye ve benzer, basit bir tartışma forumu uygulamaya çalışıyorum. Ben de github IDDD örnekleri kontrol ettik. Davam için Kimlik ve Erişimi kabul etmekte bazı zorluklar yaşıyorum. Arka plan bilgisi vereyim:

• (Umarım) kullanıcıları ve izinler mantığını ayırmanın ardındaki mantığı anlıyorum: destekleyici bir alan ve farklı sınırlı bir bağlam.
• Çekirdek etki alanında kullanıcı yok, yalnızca Yazarlar, Moderatörler vb. Var. Bunlar, bir hizmet kullanarak Kimlik ve Erişim bağlamına ulaşarak ve sonra alınan Kullanıcı nesnelerini ve Moderatöre çevirerek oluşturulur.

• Etki alanı işlemleri parametre olarak ilgili bir rolle çağrılır: örn:

  ModeratePost( ..., moderator);

• Etki alanı nesnesinin yöntemi, verilen Moderator örneğinin null olup olmadığını denetler (Kimlik ve Erişim bağlamından istenen kullanıcının Moderatör rolü yoksa Moderator örneği null olur).

• Bir durumda, bir Gönderiyi değiştirmeden önce ek bir kontrol yapar:

  if (forum.IsModeratedby(moderator))

Sorularım:

• İkinci durumda, güvenlik kaygıları tekrar temel etki alanına karışmıyor mu? Daha önce kitaplar, "bir konuyu kimin gönderebileceği ya da izin verilen koşullar altında. Bir Forumun şu anda bir Yazarın bunu yaptığını bilmesi gerekiyor" demektedir.

• Kitaptaki role dayalı uygulama oldukça basittir: Bir Moderatör temel etki alanı olduğunda, mevcut userId'yi bir Moderator örneğine veya gerektiğinde bir Yazara dönüştürmeye çalışır. Kullanıcı uygun role sahip değilse hizmet uygun örneğe veya null değerine yanıt verecektir. Ancak bunu daha karmaşık bir güvenlik modeline nasıl adapte edebileceğimi göremiyorum; pilotluk yaptığım şu anki projemizde gruplar, EKL'ler vb. içeren oldukça karmaşık bir model var.

Çok karmaşık olmayan kurallarda bile: "Bir gönderi yalnızca Sahibi veya Editör tarafından düzenlenmelidir", bu yaklaşım bozulur veya en azından onu uygulamak için doğru yolu göremiyorum.

Bir OwnerOrEditor örneği için Kimlik ve Erişim bağlamını sormak doğru gelmiyor ve çekirdek etki alanında giderek daha fazla güvenlikle ilgili sınıflarla karşılaşıyorum. Buna ek olarak, sadece userId değil, korunan kaynağın (yazı, forum vb. Kimliği) güvenlik bağlamına geçmesi gerekirdi, muhtemelen bu şeyleri önemsememelidir (doğru mu? )

Çekirdek etki alanına izinleri alarak ve etki alanı nesnelerinin yöntemlerinde veya hizmetlerinde denetleyerek, birinci kareye geliyorum: güvenlik endişelerini etki alanı ile karıştırmak.

Güvenlik ve izinler temel etki alanı değilse, bir yerde okudum (ve kabul ediyorum) bu izinle ilgili şeylerin temel etki alanının bir parçası olmaması gerekir. Yukarıda verilen gibi basit bir kural, güvenliği temel alanın bir parçası haline getirmeyi haklı çıkarıyor mu?

Gerçek erişim kontrol kuralları ile erişim kontrolünde sınır çizgisi olan alan değişmezleri arasında ayrım yapmak bazen zor olabilir.

Özellikle, yalnızca belirli bir etki alanı mantığı parçasına kadar olan verilere bağlı olan kurallar, etki alanından kolayca çıkarılamaz. Erişim Denetimi genellikle bir etki alanı işlemi gerçekleştirilmeden önce veya sonra çağrılır, ancak sırasında çağrılmaz.

Vaughn Vernon assert (forum.IsModeratedBy(moderator))örneği muhtemelen Alan adının dışında olmalıdır, ancak her zaman mümkün değildir.

Ben sadece userId değil, muhtemelen bu şeyler (bu doğru mu?

Bir Güvenlik BC'si varsa ve bu mantığı işlemesini istiyorsanız, bir Forumun ayrıntılı olarak ne olduğunu bilmek zorunda değildir, ancak:

• Sadece "yöneten" gibi kavramlar hakkında bilgi sahibi olabilir ve buna göre erişim hakları verebilir veya reddedebilir.
• Çekirdek Etki Alanı olaylarına abone olan ve bunları Güvenlik BC'nin depolaması ve kullanması için basit (kaynak, yetkili kullanıcı) anahtar değeri çiftlerine çeviren bağdaştırıcı mantığınız olabilir.

Kimlik Doğrulama ve Yetkilendirme DDD için kötü bir örnektir.

Şirketiniz güvenlik ürünleri oluşturmadığı sürece bunların hiçbiri bir Alanın parçası değildir.

İşletme veya alan adı gereksinimi "Role dayalı kimlik doğrulaması istiyorum" olmalıdır veya olmalıdır

Daha sonra bir etki alanı işlevini çağırmadan önce rolü kontrol edersiniz.

'Kendi gönderilerimi düzenleyebilirim ancak başkalarını değil' gibi karmaşık gereksinimleriniz varsa, alan adınızın düzenleme işlevini ayırdığından emin olun EditOwnPost()ve EditOthersPost()böylece rol eşlemesi için basit bir işleve sahip olun.

Ayrıca , yönteminizin bir Etki Alanı Hizmetinde mi yoksa bir Etki Alanı Nesnesinde mi olduğuna bağlı olarak, işlevselliği Etki Alanı Nesneleri gibi ayırtabilirsiniz Poster.EditPost()ve Moderator.EditPost()bu daha OOP yaklaşımıdır.

Ancak, Rol eşlemesinin Etki Alanı dışında gerçekleşeceği kodu ayırmayı seçersiniz. örneğin bir webapi denetleyiciniz varsa:

PostController : ApiController
{
    [Authorize(Roles = "User")]
    public void EditOwnPost(string postId, string newContent)
    {
        this.postDomainService.EditOwnPost(postId, string newContent);
    }

    [Authorize(Roles = "Moderator")]
    public void EditOtherPost(string postId, string newContent)
    {
        this.postDomainService.EditOtherPost(postId, string newContent);
    }
}

Rol eşlemesinin barındırma katmanında yapılmasına rağmen, kendi veya başka bir postayı düzenlemenin neyin karmaşık mantığı alan adının bir parçasıdır.

Etki alanı eylemlerin farkını tanır, ancak güvenlik gereksinimi basitçe "işlevsellik rollerle sınırlanabilir" dir .

Bu belki de etki alanı nesnelerinin ayrılmasıyla daha açıktır, ancak aslında hizmet yöntemini çağıran yöntem yerine nesneyi oluşturan yöntemi kontrol edersiniz. İhtiyacınız, hala etki alanının bir parçası olarak seslendirmek istiyorsanız 'yalnızca moderatörler moderatör nesnesini oluşturabilir'