Tüm bu hizmetlerle nasıl anemik olamam?

Delegasyon ile iş mantığının kapsüllenmesi arasındaki çizgiyi nerede çizeriz? Bana öyle geliyor ki, delege arttıkça, o kadar anemik oluyoruz. Ancak, delegasyon yeniden kullanımı ve DRY sorumlusunu da teşvik eder. Öyleyse delege etmeye uygun olan ve alan modellerimizde neler kalmalı?

Aşağıdaki endişeleri örnek olarak alın:

Yetkilendirme . Etki alanı nesnesi erişim kontrolü kurallarını (CanEdit özelliği gibi) korumaktan mı sorumlu olmalı, yoksa yalnızca erişimi yönetmekle yükümlü olan başka bir bileşen / hizmete devredilmeli mi, örneğin IAuthorizationService.CanEdit (object)? Yoksa ikisinin birleşimi mi olmalı? Belki de etki alanı nesnesinin, asıl işi gerçekleştirmek için dahili bir IAuthorizationService'e yetki veren bir CanEdit özelliği vardır?

Doğrulama . Yukarıdakiyle aynı tartışma, doğrulama ile ilgilidir. Kuralları kim korur ve onları değerlendirmekten kim sorumludur? Bir yandan, nesnenin durumu o nesneye ait olmalıdır ve geçerlilik bir durumdur, ancak her etki alanı nesnesinin kurallarını değerlendirmek için kullanılan kodu yeniden yazmak istemiyoruz. Biz olabilir bu durumda miras kullanmayı ...

Nesne Yaratma . Fabrika sınıfı ve fabrika yöntemlerine karşı bir örneği 'yenileştirme'. Ayrı bir fabrika sınıfı kullanırsak, yaratma mantığını izole edebilir ve kapsüllenebiliriz, ancak nesnemizin durumunu fabrikaya açmak pahasına. Etki alanı katmanımız fabrika tarafından kullanılan bir iç kurucuyu açığa çıkararak ayrı bir derlemede ise bu yönetilebilir, ancak birden fazla yaratma modeli varsa bu bir sorun haline gelir. Ve eğer bütün fabrika yapıyorsa doğru kurucuyu çağırıyorsa, fabrikaya sahip olmanın amacı nedir?

Sınıftaki fabrika yöntemleri, nesnenin iç durumunu açmakla ilgili sorunu ortadan kaldırır, ancak statik olduklarından, ayrı bir fabrika sınıfında olduğu gibi bir fabrika arabiriminin enjeksiyonu yoluyla bağımlılıkları kıramazız.

Sebat . Etki alanı nesnemiz, yetkilendirme kontrolünü başka bir tarafa (IAuthorizationService) gerçekleştirme sorumluluğunu verirken CanEdit'i ifşa ederse, neden aynı şeyi yapan etki alanı nesnesinde bir Kaydet yöntemine sahip olmadığımızı iddia edebilir? Bu, işlemin enkapsülasyonu bozmadan gerçekleştirilip gerçekleştirilemeyeceğini belirlemek için nesnenin iç durumunu değerlendirmemizi sağlayacaktır. Tabii ki, depo örneğini bana biraz kokan etki alanı nesnesine enjekte etmemizi gerektiriyor, bunun yerine bir etki alanı olayı ortaya çıkarıyoruz ve bir işleyicinin kalıcılık işlemini gerçekleştirmesine izin veriyoruz?

Bununla nereye gittiğimi görüyor musun?

Rockford Lhotka, CSLA çerçevesi için Ücretli Sınıf rotasına gitme nedenleri hakkında harika bir tartışmaya sahip ve bu çerçeveyle ilgili bir miktar geçmişim var ve iş nesnesi fikrini, etki alanı nesnelerini paralel olarak birçok yönden görebiliyor. Ancak iyi DDD ideallerine daha bağlı olmaya çalışıyorum, işbirliğinin ne zaman çok fazla olduğunu merak ediyorum.

Topluluğum için IAuthorizationService, IValidator, IFactory ve IRepository ile sonuçlanırsam geriye ne kalır? Sınıfı anemik olmayan bir etki alanı nesnesi olarak kabul etmek için Nesnenin durumunu Taslaktan Yayınlanmış'a değiştiren bir Yayınlama yöntemine sahip olmak mı?

Senin düşüncelerin?

Karışıklığın çoğu, etki alanı modelinde hiç olmaması gereken işlevler etrafında görünmektedir:

• Kalıcılık asla etki alanı modelinde olmamalıdır. Asla asla Bu IRepository, modelin bir kısmının, modelin farklı bir bölümünü almak gibi bir şey yapması gerekip gerekmediğini uygulamak için bağımlılık enjeksiyonunu veya benzeri bir tekniği kullanmak gibi soyut türlere güvenmenizin nedenidir . Öyleyse rekordan vur.

• Yetkilendirme , genellikle etki alanının bir parçası değilse, örneğin güvenlik yazılımı yazıyorsanız, genellikle etki alanı modelinizin bir parçası değildir . Bir uygulamada normalde iş / etki alanı katmanının "kenarında" işleneni gerçekleştiren makineyi yapanlar, kullanıcı arayüzü ve Entegrasyon parçalarının konuşmasına izin verilen kamu parçaları - MVC, Kontrolör veya mesajlaşma sisteminin kendisi bir SOA'da ... resmi alırsınız.

• Fabrikalar (ve burada soyut fabrikalar demek istediğinizi varsayalım) bir etki alanı modelinde bulunmak tamamen fena değil , ancak neredeyse her zaman gereksiz. Normalde, yalnızca nesne oluşturma iç mekaniğinin değişebileceği bir fabrikanız olur. Ancak, etki alanı modelinin yalnızca bir uygulamasına sahipsiniz, bu da her zaman aynı yapıcıları ve diğer başlangıç ​​kodunu çağıran yalnızca bir tür fabrika olacağı anlamına gelir.

  İsterseniz "uygunluk" fabrikalarına sahip olabilirsiniz - yapıcı parametrelerinin ortak kombinasyonlarını içeren sınıflar ve benzerleri - ama dürüst olmak gerekirse, genel olarak konuşursak, etki alanı modelinizde oturan birçok fabrika varsa, sadece satırları boşa harcıyorsunuzdur Kodun

Yani hepsini bir kez çırptığınızda, bu sadece onaylamadan çıkar. Bu biraz zor olan tek şey.

Doğrulama , etki alanı modelinizin bir parçasıdır ancak aynı zamanda uygulamanın diğer tüm bileşenlerinin bir parçasıdır. Kullanıcı Arabiriminiz ve veritabanınız, benzer ancak farklı bir kavramsal modele dayalı olarak kendi, benzer ancak farklı doğrulama kurallarına sahip olacaktır. Nesnelerin bir Validateyönteme sahip olup olmadıklarının gerçekten belirtilmemiştir, ancak bir yöntem olsa bile bunu genellikle bir doğrulama sınıfına devredeceklerdir (arabirim değil - doğrulama etki alanı modelinde soyut değildir , temeldir).

Doğrulayıcının hala teknik olarak modelin bir parçası olduğunu unutmayın; herhangi bir veri veya durum içermediğinden bir toplu köke eklenmesine gerek yoktur. Etki alanı modelleri, fiziksel olarak bir düzene veya bir düzenek derlemesine çevrilen kavramsal şeylerdir. Yetkilendirme kodunuz nesne modeline çok yakın ise, "anemik" konuyu vurgulamayın; hala sayılır.

Bu bütün bir aşağı gelir size DDD yapacaksın, sen alanı ne olduğunu anlamak zorunda olduğunu olduğunu . Eğer hala sebat ve yetkilendirme gibi şeylerden bahsediyorsan, o zaman yanlış yoldasın. Etki alanı, sistemin çalışma durumunu temsil eder - fiziksel ve kavramsal nesneler ve özellikler. Nesnelerle ve ilişkilerle doğrudan ilgili olmayan hiçbir şey etki alanı modeline, döneme ait değildir.

Genel kural olarak, bir şeyin etki alanı modelinde olup olmadığına bakarken, kendinize şu soruyu sorun:

“Bu işlev yalnızca teknik nedenlerden ötürü değişebilir mi?” Başka bir deyişle, gerçek dünyadaki iş veya etki alanında gözle görülür bir değişiklik olmadığından mı?

Cevap "evet" ise, etki alanı modeline ait değildir. Etki alanının bir parçası değil.

Bir gün kalıcılığınızı ve yetkilendirme altyapınızı değiştireceğiniz için çok iyi bir şans var. Bu nedenle, onlar etki alanının bir parçası değil, uygulamanın bir parçası. Bu aynı zamanda sıralama ve arama gibi algoritmalar için de geçerlidir; etki alanınızdaki bir ikili arama kodu uygulaması kullanmamalısınız, çünkü etki alanınız yalnızca bir aramanın soyut kavramıyla ilgilidir, nasıl çalıştığını değil.

Önemli olmayan her şeyi çıkardıktan sonra, etki alanı modelinin gerçekten anemik olduğunu görüyorsanız , bu durum DDD'nin projeniz için yanlış bir paradigma olduğunun oldukça iyi bir göstergesi olarak hizmet etmelidir.

Bazı alanlar gerçekten vardır anemik. Sosyal yer imi uygulamalarında gerçekten konuşacak bir "etki alanı" yok; Tüm nesneleriniz temelde sadece işlevselliği olmayan verilerdir. Öte yandan, bir Satış ve CRM sistemi oldukça ağır bir etki alanına sahiptir; Bir Ratevarlık yüklediğinizde , o zaman, sipariş miktarına uygulamak ve toplu indirimleri, promosyon kodlarını ve tüm bu eğlenceli şeyleri hesaplamak gibi , aslında bu oranla işlem yapabileceğinize dair makul bir beklenti vardır .

Sadece verileri tutmak Alan nesneler genellikle do bir anemik etki modeli var, ama bu olmayacağı anlamına mutlaka sadece alan adının kendisi anemik olduğu anlamına gelebilir ve bir kullanarak gerektiğini - Kötü bir tasarıma oluşturduk anlamına farklı metodoloji.

Yetki. Etki alanı nesnesi erişim denetimi kurallarını korumaktan sorumlu olmalı mı?

Hayır. Yetki kendi başına bir endişedir. İzin yetersizliğinden dolayı geçerli olmayacak olan komutlar, etki alanından önce mümkün olduğunca erken reddedilmelidir - bu, genellikle kullanıcı arayüzünü oluşturmak için potansiyel bir komutun yetkilendirmesini kontrol etmek isteyeceğimiz anlamına gelir. Hatta kullanıcıya düzenleme seçeneği göstermek).

Yetkilendirme stratejilerini katmanlar arasında (Kullanıcı Arabiriminde ve ayrıca bir hizmet veya komut işleyicisinde) paylaşma, yetkilendirme alan modelinden ayrı bir şekilde birleştirildiğinde daha kolaydır.

Karşılaşılabilecek en zor kısımlardan biri, bir komutun yalnızca kullanıcı rollerine değil iş verilerine / kurallarına göre izin verilip verilemeyeceği bağlamsal yetkilendirmedir.

Doğrulama. Yukarıdakiyle aynı tartışma, doğrulama ile ilgilidir.

Ayrıca, etki alanında değil (çoğunlukla) hayır derdim. Doğrulama farklı bağlamlarda gerçekleşir ve doğrulama kuralları genellikle bağlamlar arasında farklılık gösterir. Bir küme tarafından kapsanan veriler göz önüne alındığında, nadiren basit, mutlak bir geçerli ya da geçerli olmayan his vardır.

Ayrıca, yetkilendirme gibi, katmanlar arasında doğrulama mantığını kullanırız - kullanıcı arayüzünde, hizmet veya komut işleyicide vb. Pratik bir noktadan itibaren, doğrulama (özellikle çerçeveler kullanılırken), aksi takdirde kapsüllenmesi gereken verilerin gösterilmesini gerektirir ve genellikle alanlara ve özelliklere eklenecek özel nitelikler gerektirir. Bunları etki alanı modelleri dışındaki diğer sınıflarda olmayı tercih ederim.

Doğrulama çerçevesi için gereklilikleri benim varlıklarıma zorlamak yerine, birkaç benzer sınıftaki bazı özellikleri kopyalamayı tercih ederim. Bu kaçınılmaz olarak varlık sınıflarının bir karmaşasını ortaya çıkarır.

Nesne Yaratma. Fabrika sınıfı ve fabrika yöntemlerine karşı bir örneği 'yenileştirme'.

Bir dolaylı katmanı kullanıyorum. Daha yeni projelerimde, bu bir şeyler yaratmak için bir komut + işleyicisidir, yani CreateNewAccountCommand. Alternatifler her zaman bir fabrika kullanmak olabilir (her ne kadar bir işletme operasyonunun geri kalanı fabrika sınıfından ayrı bir servis sınıfına maruz kalıyorsa bu zor olabilir).

Yine de, genel olarak, nesne oluşturma için tasarım seçenekleriyle daha esnek olmaya çalışıyorum. newkolay ve tanıdık ama her zaman yeterli değil. Burada yargıyı kullanmak ve sistemin farklı bölümlerinin gerektiğinde farklı stratejiler kullanmasına izin vermek önemli olduğunu düşünüyorum.

Süreklilik. ... neden etki alanı nesnemizde bir Kaydet yöntemi yok?

Bu nadiren iyi bir fikirdir; Bunu desteklemek için bolca paylaşılan deneyim olduğunu düşünüyorum.

Topluluğum için IAuthorizationService, IValidator, IFactory ve IRepository ile sonuçlanırsam geriye ne kalır? Sınıfı anemik olmayan bir etki alanı nesnesi olarak kabul edecek kadar Taslaktan Nesnenin durumunu değiştiren bir Yayınlama yöntemine sahip mi ???

Belki bir etki alanı modeli, başvurunuzun bu kısmı için doğru seçim değildir.

Tamam, işte benim için. Bunu söyleyerek bunu boşvereceğim:

• Erken optimizasyon (ve tasarım içerir) sıklıkla sorunlara neden olabilir.

• IANMF (Martin Fowler değilim);)

• Kirli küçük bir sır, küçük ölçekli projelerde (tartışmalı olarak orta ölçekli olanları bile) yaklaşımınızın tutarlılık göstermesidir.

yetki

Benim için Kimlik Doğrulama ve Yetkilendirme her zaman çapraz bir endişe kaynağıdır. Mutlu küçük Java dünyamda, bu Bahar güvenliğine veya Apache Shiro çerçevesine delege ediliyor.

Doğrulama Benim için doğrulama, nesnenin ne olduğunu tanımlarken gördüğüm gibi nesnenin bir parçasıdır.

Örneğin, bir Araba nesnesinin 4 tekerleği var (Tamam, bazı garip istisnalar var, ancak şimdilik garip 3 tekerlekli Araba'yı görmezden gelelim). Bir Araba 4 olmadıkça geçerli değildir (benim dünyamda), bu yüzden doğrulama bir Araba tanımının bir parçası. Bu, yardımcı doğrulama sınıflarına sahip olamayacağınız anlamına gelmez.

Mutlu Java dünyamda Bean doğrulama çerçevelerini kullanıyorum ve Bean alanlarımın çoğunda basit açıklamalar kullanıyorum. Hangi katmanda olursanız olun, nesnenizi doğrulamak kolaydır.

Nesne Oluşturma

Fabrika sınıflarını dikkatle inceliyorum. Çok sık xyxFactoryFactorydersi gördüm ;)

newBağımlılık Enjeksiyonunun garanti altına alındığı bir durumla karşılaşana kadar (ve bir TDD yaklaşımını izlemeye çalıştığım için, bu olmamasından daha sık ortaya çıkıyor), sadece gerektiği gibi bir nesne yaratma eğilimindeyim .

Mutlu Java dünyamda bu giderek daha fazla Guice, ancak Bahar'ın hala burada Kral.

Süreklilik

Yani bu dairelerde ve kavşaklarda devam eden bir tartışma ve ben her zaman bu konuda iki kafadayım.

Bazıları nesneye 'saf' bir şekilde bakarsanız kalıcılığın temel bir özellik olmadığını, bunun yalnızca dışsal bir mesele olduğunu söylüyor.

Diğerleri etki alanı nesnelerinizin 'kalıcı' bir arabirim oluşturduğunu kabul eder (evet, burada gergin olduğumu biliyorum). Bu nedenle, üzerlerinde çeşitli save, deletevb yöntemlerin olması iyidir . Bu pratik bir yaklaşım olarak görülüyor ve birçok ORM teknolojisi (mutlu Java dünyamda JPA) nesnelerle bu şekilde ilgileniyor.

Kesişen bir güvenlik endişesinden, nesnede kaydet / güncelle / sil yöntemini çağıran hizmette düzenleme / sil / ekle / hangi izinlerin doğru ayarlandığından emin olun. Gerçekten paranoyak olduğum takdirde etki alanı nesnesinin izinlerini bile ayarlayabilirim.

HTH!

Jimmy Nilsson DDD'deki kitabında bu konuya değiniyor. Anemik bir modelle başladı, daha sonraki bir projede anemik olmayan modellere gitti ve sonunda anemik modellere yerleşti. Akıl yürütme, anemik modellerin farklı iş mantığı ile birden fazla hizmette yeniden kullanılabileceği yönündeydi.

Ticarette keşif kabiliyeti eksikliği var. Anemik modelinizde kullanmak için kullanabileceğiniz yöntemler, başka bir yerde bulunan bir dizi hizmete yayılmıştır.

Bu soru uzun zaman önce soruldu, ancak Domain Driven Design ile etiketlendi. Sorunun kendisinin tüm uygulamanın temel bir yanlış anlaşılmasını içerdiğini ve kabul edilen cevap da dahil olmak üzere cevapların temel bir yanlış anlaşılmayı sürdürdüğünü düşünüyorum.

DDD mimarisinde "etki alanı modeli" yok.

Örnek olarak Yetki alalım. Bir soru hakkında düşünmenizi isteyeyim: İki farklı kullanıcının sisteminizde kimliğini doğruladığını hayal edin. Bir kullanıcı belirli bir Varlığı değiştirme iznine sahiptir, ancak diğeri değişmez. Neden olmasın?

Basit ve tartışmalı örneklerden nefret ediyorum, çünkü genellikle aydınlattıklarından daha fazla kafa karıştırıyorlar. Ama iki farklı alanımız varmış gibi yapalım. Birincisi, bir pazarlama ajansı için bir CMS platformudur. Bu ajansın, çevrimiçi olarak kopya yazarları ve grafik sanatçıları tarafından yönetilmesi gereken içeriği olan birçok müşterisi vardır. İçerik, blog gönderilerinin yanı sıra farklı müşteriler için açılış sayfalarını da içeriyor.

Diğer etki alanı bir ayakkabı şirketi için envanter yönetimidir. Sistem, Fransa'daki üreticiden, Amerika kıtasındaki dağıtım merkezlerine, yerel pazarlardaki perakende mağazalarına ve en sonunda perakende mağazayı alan müşteriye envanteri yönetmektedir.

Yetkilendirme kurallarının her iki şirket için de aynı olduğunu düşünüyorsanız, evet, bu etki alanı dışındaki bir hizmet için iyi bir aday olacaktır. Ancak Yetkilendirme kurallarının aynı olduğundan şüpheliyim. Kullanıcıların arkasındaki kavramlar bile farklı olurdu. Kesinlikle dil farklı olurdu. Pazarlama ajansı, muhtemelen yazar ve mal sahibi gibi roller üstlenirken, ayakkabı şirketinin muhtemelen nakliye memuru veya depo yöneticisi veya mağaza yöneticisi gibi rolleri vardır.

Bu kavramlar, muhtemelen, etki alanında modellenmesi gereken, kendileriyle ilişkili her türlü izin kurallarına sahiptir. Ancak bu, aynı uygulama içinde bile hepsinin aynı modelin parçası olduğu anlamına gelmez. Çünkü farklı Sınırlı Bağlamların olduğunu unutmayın.

Bu nedenle, belki de yetkilendirme bağlamında anemik olmayan bir etki alanı modeli, ayakkabıların düşük envanterli mağazalara yönlendirilmesi veya site ziyaretçilerini, hangi reklamı tıkladıklarına bağlı olarak uygun açılış sayfasına yönlendirmesi bağlamında farklı olabilir.

Kendinizi anemik etki alanı modelleriyle bulursanız, kod yazmaya başlamadan önce içerik eşlemesi için daha fazla zaman harcamanız gerekebilir.