ORM'li DDD iş mantığı nereye gitmeli?


10

Geçmişte UML ile modellenmiş olduğumuz bir MDA (model odaklı mimari) aracı kullandım ve bu, diğer şeylerin yanı sıra iş varlıklarını (alan modelimiz) ve ORM'yi (haritalama vb.) Üretti.

Alanda çalışan işletme kodu ve hizmetlerin çoğu modelin bir parçasıydı ve depolarımız ticari varlıkları iade ediyordu (bu yüzden başka bir ORM'ye geçmek imkansız olurdu (istediğimiz değil)).

Ancak, şimdi bir proje başlatıyorum ve DDD açısından düşünmek istiyorum.

Şimdiye kadar iş mantığımı etki alanı modelime koyduğum ve depolarla ORM ile çalışacağım (ki seçtiğim). Ancak, uygulamanın ORM kısmı için MDA aracını kullanmaya devam etmek istersem, burada oluşturulan model çok anemik olacaktır (yani herhangi bir iş mantığı içermez). Benzer şekilde ORM için Entity framework (.net) veya NHibernate kullandıysam da anemik bir model olurdu. Sadece NHibernate kullandıysam iş mantığını nereye koyacağınızdan emin değilim.

Bu şekilde düşünerek doğru muyum, diğer bir deyişle DDD ile etki alanındaki tüm iş mantığı ve depolar aracılığıyla kalıcılık için ORM'yi kullanıyorum?

Yanıtlar:


12

bu yüzden başka bir ORM'ye geçmek imkansız olurdu (istediğimiz değil).

Bu yanlış görünüyor. Havuz deseninin en büyük avantajı, veri erişim mantığını gizlemeniz ve kolayca değiştirilebilmesidir.

Şimdiye kadar iş mantığımı etki alanı modelime koyduğum ve depolarla ORM ile çalışacağım (ki seçtiğim). Ancak, uygulamanın ORM kısmı için MDA aracını kullanmaya devam etmek istersem, burada oluşturulan model çok anemik olacaktır (yani herhangi bir iş mantığı içermez). Benzer şekilde ORM için Entity framework (.net) veya NHibernate kullandıysam da anemik bir model olurdu. Sadece NHibernate kullandıysam iş mantığını nereye koyacağınızdan emin değilim.

Anemik etki alanı modeli, birçok kişi tarafından, örneğin Martin Fowler tarafından kötü bir uygulama olarak kabul edilir. Böyle bir tasarımdan kaçınmalısınız çünkü böyle bir model iyi bir nesne yönelimli tasarımdan ziyade prosedürel tasarım tekniklerine yol açar. Daha sonra veri sınıfları ve yönetici / işleme sınıflarınız olur, bu da durumu ve davranışı ayırdığınız anlamına gelir. Fakat bir nesne gerçekten "durum ve davranış" olmalıdır.

NHibernate kalıcılık cehaletinde iyi bir iş çıkarıyor. XML veya FluentNHibernate ile eşleme ayrıntılarını gizleyebilir ve sadece düz POCO'lar yazabilirsiniz. NHibernate ile zengin bir etki alanı modeli oluşturmak çok kolaydır. Bunu varlık çerçevesi ve MDA aracıyla da yapabileceğinizi düşünüyorum. Bu araç kısmi sınıflar ürettiği sürece, yeni nesil kullanıcı tarafından yazılan kodunuzu yok edebileceğinden endişe etmeden oluşturulan kodu oldukça kolay bir şekilde genişletebilirsiniz.

Bu uzun hikayeyi kısaltmak için. Eğer NHibernate, hiçbir şey kullandığınızda, tekrar ediyorum hiçbir şey , zengin alanı modeli kucaklayan alıkoyar. FluentNHibernate ile kullanmanızı ve elle eşlemenizi tavsiye ederim. Eşleme kodunun yazılması yalnızca 5 ila 10 dakika sürer. Aynı şeyin varlık çerçevesi için de geçerli olduğunu ve araçlarının en azından kolayca genişletilebilen kısmi sınıflar oluşturduğunu düşünüyorum.

Bu şekilde düşünerek doğru muyum, diğer bir deyişle DDD ile etki alanındaki tüm iş mantığı ve depolar aracılığıyla kalıcılık için ORM'yi kullanıyorum?

Çoğunlukla haklısın. Zengin bir alan adı modeline sahip olmalısınız. Özellikle işler gittikçe daha karmaşık hale geldiğinde, düzgün bir şekilde tasarladığınızda bakımı ve genişletilmesi daha kolaydır. Ancak DDD'nin ayrıca iş mantığını uygulamak için (Domain Layer ve Application Layer) Hizmetlerini ve yaratıcı mantığı kapsüllemek için Fabrikaları da bildiğini unutmayın.

Ayrıca iş mantığını alan mantığı ve gerçek uygulama iş mantığına ayırma eğilimindeyim. Etki alanı mantığı, tamamen farklı bir katman olan uygulama mantığı, etki alanının belirli kullanım durumu / uygulama için nasıl kullanıldığını kapsarken, etki alanının nasıl etkileştiği ve davrandığıdır. Çoğu zaman, belirli kullanım örneklerini desteklemek ve daha güçlü hale getirmek için etki alanı modelini güncellemem gerekir.


2
+1: Ayrıca, etki alanı mantık katmanını uygulama mantığı katmanından ayırırım. Etki alanı mantık katmanı tüm ORM ve veritabanı şeyler koymak. Uygulama mantığı katmanı, ORM, işlemler ve tüm bunlar hakkında hiçbir şey bilmez: sadece iş mantığı sınıflarını görür ve yöntemlerini çağırır. Bu yaklaşımı daha basit ve daha temiz bir uygulama mantık katmanına sahip olmak için çok etkili buluyorum.
Giorgio

@Falcon: Bilgi için teşekkürler. DDD kullanarak bir etki alanı oluşturursam, anemik modelden bahsettiğimde, depolarımın bir sürümü, yalnızca varlıklarımı mda varlıklarına (yani anemik model) taşıyacağım ve sonra da devam edeceğim mda sürümü olurdu. Bu sorun olur mu? MDA aracını kullanacağımdan şüpheliyim ama istersem nasıl yapabileceğimi anlamaya çalışıyorum. Kulağa doğru geliyor mu?
JD01

@ JD01: Sizi tam olarak anlamıyorum, ancak etki alanı modeli varlıklarını dönüştürmek istediğiniz gibi geliyor, böylece onları kolayca devam ettirebilirsiniz. DTO'ları kullanmak ve tıpkı (google it) böyle bir görev için yararlı bir araç olabilir. Böyle bir yaklaşım DDD'nin en iyi uygulamalarına mutlaka müdahale etmez. Sonuçta, havuzlar Veri Erişim Mantığını gizlemek içindir. İş nesnelerinizi perde arkasındaki MDA DTO'lara dönüştürebilir ve daha sonra bunları saklayabilirsiniz ve API kullanıcısı bile fark etmez. Bence sorun yok.
Falcon

1
@ JD01: Kaç tane Kurumsal Java'nın bunu yaptığını görmek için aşağıdaki bağlantıya göz atmanızı öneririm. Temelde bir DAO, bir DTO ve BO (İş nesnesi) var. Benim için, bu çok fazla katman ama tasarım tamam. java.sun.com/blueprints/corej2eepatterns/Patterns/…
Falcon

@Falcon: Evet, DTO'ların MDA nesnelerim olduğunu düşünüyordum, bu şekilde gideceğimden değil. Sadece DDD oyuncularının her bir parçasının d0 ne olduğunu kavramak. Tekrar teşekkürler.
JD01

3

Ancak, uygulamanın ORM kısmı için MDA aracını kullanmaya devam etmek istersem, burada oluşturulan model çok anemik olacaktır (yani herhangi bir iş mantığı içermez).

Hangi MDA aracını kullandığınızı bilmiyorum, ancak birlikte çalıştığım araçlar her zaman kısmi sınıflar oluşturuyor, böylece bunları istediğiniz kadar iş mantığıyla tamamlayabilirsiniz.

Bununla birlikte, MDA araçlarının bir DDD bağlamında ORM'lerden biraz daha az uygun olduğunu düşünüyorum, çünkü kod üretimi genellikle beklediğimiz aerodinamik, açıkça ifade edilen etki alanı varlıkları yerine araca özgü gürültü ile karışan sınıflar üretme eğilimindedir. Aslında, sık sık elde ettiğiniz alan adı verileri, kalıcılık mantığı, kısıtlama doğrulama mantığı ... ve bu endişeleri çoğu MDA aracıyla ayırmanın bir yolu olup olmadığını bilmiyorum.

Ve elbette, kısmi sınıflar dışında oluşturulan koda dokunamazsınız, yani entegre edilecek potansiyel DDD karşıtı davranışları ortadan kaldıramazsınız. Bu, Agregalar arasındaki katı engelleri uygulamak ve varlıklarınız arasındaki ilişkileri mükemmel bir şekilde uyarlamak istediğiniz bir yaklaşımda sorunludur. Sürekli bir entegrasyon ortamında inşa süresi de ek kod oluşturma adımından etkilenebilir.

Bunun dışında, Falcon'un neredeyse hepsini söylediğini düşünüyorum - ORM veya MDA araçlarında kesinlikle hiçbir şey zengin etki alanı varlıklarına sahip olmanızı engellemiyor.


Merhaba, capableobjects.com ECO (kurumsal temel nesneler) kullanıyorum ve tam olarak tarif ettiğiniz gibi.
JD01

1

Ekibimde yaptığım şey nesnemi, etki alanımı modellemek ve aynı zamanda iş mantığımı eklemek. Bir modelden kod oluşturacak ancak açıklama yaklaşımını tercih eden Model Odaklı Geliştirme kullanmıyorum. Yani sınıf diyagramının içindeki nesne seviyesinde ORM stereotipleri ekliyorum. Bu, doğrudan EJB3 / hibernate ile uyumlu olan kodda kalıcılık ek açıklamaları ekleyecektir. Veritabanı oluşturma Hibernate tarafından yapılır ve kesinlikle UML şablonları tarafından yapılmaz. Bu çok daha iyi çünkü kod değiştiğinde ve eklenen ek açıklamalar tam olarak hazırda bekletme uzmanı değilse, değiştirebilir, ancak model hala iyidir. Ayrıca gereksinimlerimi değiştirebilirim ve etki alanı modelim hala iyi.

Geliştiriciler her yöntemin içine iş mantığı ekleyebilir ve yorum ekleyebilir, ben de modelleme ve kısıtlama ekleyebilirsiniz. Örneğin satışlar vb değilse 50k üzerinde olmalıdır .... Ben kodlamak gerekmez ama sadece modelinde yazın ve bu bilgiler geliştirici ekibi tarafından görülebilir. Gerçekten harika ve esnek UML.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.