Zengin ve Anemik Alan Modeli [kapalı]

Anemik Alan Modeli yerine Zengin Alan Modeli kullanıp kullanmayacağıma karar veriyorum ve bu ikisinin iyi örneklerini arıyorum.

Bir Hizmet -> Depo -> Depolama katmanı sistemi tarafından desteklenen Anemik Etki Alanı Modeli kullanarak , BL doğrulaması için FluentValidation kullanarak ve tüm BL'mi Hizmet katmanına yerleştirerek web uygulamaları oluşturuyorum.

Eric Evan'ın DDD kitabını okudum ve o (Fowler ve diğerleri ile birlikte) Anemik Alan Modellerinin bir anti-model olduğunu düşünüyor gibi görünüyor.

Bu yüzden gerçekten bu problem hakkında biraz fikir edinmek istiyordum.

Ayrıca, Zengin Etki Alanı Modelinin bazı iyi (temel) örneklerini ve sağladığı Anemik Etki Alanı Modeline göre faydaları gerçekten arıyorum.

Fark, anemik bir modelin mantığı verilerden ayırmasıdır. Mantık genellikle adlandırılmış sınıflara yerleştirilir **Service, **Util, **Manager, **Helperve bu kadar. Bu sınıflar veri yorumlama mantığını uygular ve bu nedenle veri modelini bir argüman olarak alır. Örneğin

public BigDecimal calculateTotal(Order order){
...
}

zengin alan yaklaşımı, veri yorumlama mantığını zengin alan modeline yerleştirerek bunu tersine çevirir. Böylece mantık ve verileri bir araya getirir ve zengin bir alan modeli şöyle görünür:

order.getTotal();

Bunun nesne tutarlılığı üzerinde büyük bir etkisi vardır. Veri yorumlama mantığı verileri sarmaladığından (verilere yalnızca nesne yöntemleriyle erişilebilir), yöntemler diğer verilerin durum değişikliklerine tepki verebilir -> Bu davranış dediğimiz şeydir.

Anemik bir modelde, veri modelleri yasal bir durumda olduklarını garanti edemezken, zengin bir alan modelinde olabilirler. Zengin bir alan modeli, kapsülleme, bilgi gizleme ve veri ile mantığı bir araya getirme gibi OO ilkelerini uygular ve bu nedenle anemik bir model, OO açısından bir anti modeldir.

Daha derin bir anlayış için bloguma bir göz atın https://www.link-intersystems.com/blog/2011/10/01/anemic-vs-rich-domain-models/

Bozhidar Bozhanov, bu blog gönderisinde anemik model lehine bir iddiada bulunuyor gibi görünüyor .

İşte sunduğu özet:

• etki alanı nesneleri yay (IoC) ile yönetilmemeli, DAO'lara veya bunlara enjekte edilmiş altyapı ile ilgili herhangi bir şeye sahip olmamalıdır

• etki alanı nesneleri, hazırda bekletme (veya kalıcılık mekanizması) tarafından ayarlanmış bağımlı oldukları etki alanı nesnelerine sahiptir.

• etki alanı nesneleri, DDD'nin temel fikri olduğu gibi iş mantığını gerçekleştirir, ancak bu, veritabanı sorgularını veya CRUD'yi içermez - yalnızca nesnenin dahili durumundaki işlemler

• nadiren DTO'lara ihtiyaç vardır - etki alanı nesneleri çoğu durumda DTO'ların kendisidir (bu da bazı standart kodlardan tasarruf sağlar)

• hizmetler CRUD işlemlerini gerçekleştirir, e-postalar gönderir, etki alanı nesnelerini koordine eder, birden çok etki alanı nesnesine dayalı raporlar oluşturur, sorgu yürütür vb.

• hizmet (uygulama) katmanı o kadar ince değildir, ancak etki alanı nesnelerine özgü iş kurallarını içermez

• kod üretiminden kaçınılmalıdır. Soyutlama, tasarım kalıpları ve DI, kod üretme ihtiyacının üstesinden gelmek ve nihayetinde kod tekrarından kurtulmak için kullanılmalıdır.

GÜNCELLEME

Yakın zamanda yazarın bir tür karma yaklaşımı izlemeyi savunduğu bu makaleyi okudum - etki alanı nesneleri yalnızca durumlarına dayalı olarak çeşitli soruları yanıtlayabilir (ki bu, tamamen anemik modeller durumunda muhtemelen hizmet katmanında yapılır)

Benim bakış açım şu:

Anemik etki alanı modeli = nesnelere eşlenmiş veritabanı tabloları (yalnızca alan değerleri, gerçek davranış yok)

Zengin etki alanı modeli = davranışı açığa çıkaran nesneler koleksiyonu

Basit bir CRUD uygulaması oluşturmak istiyorsanız, klasik MVC çerçevesine sahip anemik bir model belki yeterli olabilir. Ancak bir tür mantık uygulamak istiyorsanız, anemik model, nesne yönelimli programlama yapmayacağınız anlamına gelir.

* Nesne davranışının kalıcılıkla ilgisi olmadığını unutmayın. Etki alanı nesnelerinin kalıcı olmasından farklı bir katman (Veri Eşleştiricileri, Depolar vb.) Sorumludur.

Öncelikle bu makaledeki cevabı kopyaladım http://msdn.microsoft.com/en-gb/magazine/dn385704.aspx

Şekil 1, temelde alıcılar ve ayarlayıcılar içeren bir şema olan Anemik Etki Alanı Modelini gösterir.

Figure 1 Typical Anemic Domain Model Classes Look Like Database Tables

public class Customer : Person
{
  public Customer()
  {
    Orders = new List<Order>();
  }
  public ICollection<Order> Orders { get; set; }
  public string SalesPersonId { get; set; }
  public ShippingAddress ShippingAddress { get; set; }
}
public abstract class Person
{
  public int Id { get; set; }
  public string Title { get; set; }
  public string FirstName { get; set; }
  public string LastName { get; set; }
  public string CompanyName { get; set; }
  public string EmailAddress { get; set; }
  public string Phone { get; set; }
}

Bu daha zengin modelde, yalnızca okunacak ve yazılacak mülkleri açığa çıkarmak yerine, Müşterinin kamusal yüzeyi açık yöntemlerden oluşur.

Figure 2 A Customer Type That’s a Rich Domain Model, Not Simply Properties

public class Customer : Contact
{
  public Customer(string firstName, string lastName, string email)
  {
    FullName = new FullName(firstName, lastName);
    EmailAddress = email;
    Status = CustomerStatus.Silver;
  }
  internal Customer()
  {
  }
  public void UseBillingAddressForShippingAddress()
  {
    ShippingAddress = new Address(
      BillingAddress.Street1, BillingAddress.Street2,
      BillingAddress.City, BillingAddress.Region,
      BillingAddress.Country, BillingAddress.PostalCode);
  }
  public void CreateNewShippingAddress(string street1, string street2,
   string city, string region, string country, string postalCode)
  {
    ShippingAddress = new Address(
      street1,street2,
      city,region,
      country,postalCode)
  }
  public void CreateBillingInformation(string street1,string street2,
   string city,string region,string country, string postalCode,
   string creditcardNumber, string bankName)
  {
    BillingAddress = new Address      (street1,street2, city,region,country,postalCode );
    CreditCard = new CustomerCreditCard (bankName, creditcardNumber );
  }
  public void SetCustomerContactDetails
   (string email, string phone, string companyName)
  {
    EmailAddress = email;
    Phone = phone;
    CompanyName = companyName;
  }
  public string SalesPersonId { get; private set; }
  public CustomerStatus Status { get; private set; }
  public Address ShippingAddress { get; private set; }
  public Address BillingAddress { get; private set; }
  public CustomerCreditCard CreditCard { get; private set; }
}

Zengin alan sınıflarının faydalarından biri, herhangi bir katmandaki nesneye başvurduğunuz her seferinde davranışlarını (yöntemlerini) çağırabilmenizdir. Ayrıca, birlikte iş birliği yapan küçük ve dağıtılmış yöntemler yazma eğilimindesiniz. Anemik alan sınıflarında, genellikle kullanım senaryosuna göre yönlendirilen dolgun prosedürel yöntemler (hizmet katmanında) yazma eğilimindesiniz. Zengin alan sınıflarına kıyasla genellikle daha az bakım gerektirirler.

Davranışlara sahip alan sınıflarına bir örnek:

class Order {

     String number

     List<OrderItem> items

     ItemList bonus

     Delivery delivery

     void addItem(Item item) { // add bonus if necessary }

     ItemList needToDeliver() { // items + bonus }

     void deliver() {
         delivery = new Delivery()
         delivery.items = needToDeliver()
     }

}

Yöntem needToDeliver(), bonus dahil teslim edilmesi gereken öğelerin listesini döndürür. Sınıf içinde, ilgili başka bir sınıftan veya başka bir katmandan çağrılabilir. Örneğin, Ordergörüntülemeye geçerseniz, kullanıcı tarafından onaylanacak öğelerin listesini görüntülemek için needToDeliver()seçili öğesini kullanabilirsiniz .OrderOrder

Yoruma Yanıt Verme

Controller'daki etki alanı sınıfını şu şekilde kullanıyorum:

def save = {
   Order order = new Order()
   order.addItem(new Item())
   order.addItem(new Item())
   repository.create(order)
}

Yaratılması Orderve LineItemtek işlemde. Bunlardan biri LineItemoluşturulamazsa, hiçbir Orderoluşturulmayacaktır.

Tek bir işlemi temsil eden yönteme sahip olma eğilimindeyim, örneğin:

def deliver = {
   Order order = repository.findOrderByNumber('ORDER-1')
   order.deliver()       
   // save order if necessary
}

İçindeki deliver()her şey tek bir işlem olarak yürütülecektir. Tek bir işlemde birçok ilgisiz yöntemi yürütmem gerekirse, bir hizmet sınıfı oluşturabilirim.

Tembel yükleme istisnasını önlemek için, JPA 2.1 adlı varlık grafiği kullanıyorum. Örneğin, teslimat için denetleyici ekranında, deliveryöznitelik yüklemek ve yok saymak için bir yöntem oluşturabilirim bonus, örneğin repository.findOrderByNumberFetchDelivery(). Bonus ekranında, bonusöznitelik yükleyen ve yok sayan başka bir yöntemi çağırıyorum delivery, örneğin repository.findOrderByNumberFetchBonus(). deliver()Bonus ekranından hala arayamadığım için bu disiplin gerektirir .

Monolitik masaüstü uygulamaları yazarken eskiden onları oluşturmaktan zevk almak için zengin alan modelleri oluşturdum.

Şimdi küçük HTTP mikro hizmetleri yazıyorum, anemik DTO'lar da dahil olmak üzere olabildiğince az kod var.

Bence DDD ve bu anemik argüman monolitik masaüstü veya sunucu uygulaması çağından geliyor. O dönemi hatırlıyorum ve anemik modellerin tuhaf olduğuna katılıyorum. Büyük bir monolitik FX ticaret uygulaması geliştirdim ve hiçbir model yoktu, gerçekten korkunçtu.

Mikro hizmetlerle, zengin davranışlarıyla küçük hizmetler, muhtemelen bir etki alanı içinde oluşturulabilir modeller ve kümelerdir. Dolayısıyla, mikro hizmet uygulamalarının kendisi daha fazla DDD gerektirmeyebilir. Mikro hizmet uygulaması etki alanı olabilir.

Bir sipariş mikro hizmetinin, RESTful kaynaklar olarak veya SOAP veya başka bir şekilde ifade edilen çok az işlevi olabilir. Sipariş mikro hizmet kodu son derece basit olabilir.

Daha büyük bir monolitik tek (mikro) hizmet, özellikle modelini RAM'de tutan bir hizmet, DDD'den yararlanabilir.

Bence sorunun kökü yanlış ikilemde yatıyor. Zengin ve "anemik" olmak üzere bu 2 modeli çıkarmak ve birbirleriyle karşılaştırmak nasıl mümkün olabilir? Bence bunun ancak sınıfın ne olduğuna dair yanlış fikirleriniz varsa mümkün . Emin değilim ama sanırım Youtube'daki Bozhidar Bozhanov videolarından birinde buldum. Bir sınıf, bu veriler üzerinden bir veri + yöntem değildir. Sınıfların iki kategoriye ayrılmasına yol açan tamamen geçersiz bir anlayış: yalnızca veri, yani anemik model ve veri + yöntemler - çok zengin model (daha doğru olmak gerekirse 3. kategori var: yalnızca eşit yöntemler).

Gerçek şu ki, sınıf ontolojik bir modelde bir kavram, bir kelime, bir tanım, bir terim, bir fikir, bir DENOTAT . Ve bu anlayış yanlış ikilemi ortadan kaldırır: YALNIZCA anemik modele veya YALNIZCA zengin modele sahip olamazsınız, çünkü bu, modelinizin yeterli olmadığı, gerçekle ilgili olmadığı anlamına gelir: bazı kavramların yalnızca verileri vardır, bazılarının yalnızca yöntemleri vardır, bazılarının bunlardan karışık. Bu durumda, bazı kategorileri, nesne kümelerini, ilişkileri, sınıflarla kavramları tanımlamaya çalıştığımız için ve bildiğimiz gibi, bazı kavramlar yalnızca süreçlerdir (yöntemler), bazıları yalnızca öznitelikler kümesidir (veriler), bazıları bunlar niteliklerle ilişkilerdir (karışık).

Bence yeterli bir uygulama her türden sınıfı içermeli ve fanatik olarak kendini tek bir modelle sınırlamamalıdır. Mantığın nasıl temsil ettiği önemli değil: kodla veya yorumlanabilir veri nesneleriyle ( Serbest Monadlar gibi ), yine de: süreçleri, mantığı, ilişkileri, nitelikleri, özellikleri, verileri vb. Temsil eden sınıflara (kavramlar, belirtimler) sahip olmalıyız. bazılarından kaçınmaya çalışmak ya da hepsini tek bir türe indirgemek.

Yani, mantığı başka bir sınıfa çıkarabilir ve orijinalinde veri bırakabiliriz, ancak mantıklı değildir çünkü bazı kavramlar nitelikleri ve ilişkileri / süreçleri / yöntemleri içerebilir ve bunların ayrılması, kavramı 2 isim altında çoğaltacaktır. kalıplara indirgenmiştir: "NESNE-Öznitelikleri" ve "NESNE-Mantık". Prosedürel ve işlevsel dillerde sınırlamaları nedeniyle sorun değil, ancak her türlü kavramı tanımlamanıza izin veren bir dil için aşırı bir kendini kısıtlama.

Anemik alan modelleri, ORM için önemlidir ve ağlar üzerinden kolay aktarım (tüm ticari uygulamaların can damarı), ancak OO, kodunuzun 'işlem / işleme' bölümlerini kapsüllemek ve basitleştirmek için çok önemlidir.

Bu nedenle önemli olan bir dünyayı tanımlayıp bir dünyadan diğerine dönüştürebilmektir.

Anemic, AnemicUser veya UserDAO vb. Gibi bir modele isim verin, böylece geliştiriciler kullanılacak daha iyi bir sınıf olduğunu anlar, ardından hiçbir Anemic sınıfı için uygun bir kurucuya sahip olurlar.

User(AnemicUser au)

ve taşıma / kalıcılık için anemik sınıf oluşturmak için adaptör yöntemi

User::ToAnemicUser() 

Hiçbir Anemik Kullanıcıyı taşıma / kalıcılık dışında her yerde kullanmayı hedefleyin

İşte yardımcı olabilecek bir örnek:

Anemik

class Box
{
    public int Height { get; set; }
    public int Width { get; set; }
}

Anemik olmayan

class Box
{
    public int Height { get; private set; }
    public int Width { get; private set; }

    public Box(int height, int width)
    {
        if (height <= 0) {
            throw new ArgumentOutOfRangeException(nameof(height));
        }
        if (width <= 0) {
            throw new ArgumentOutOfRangeException(nameof(width));
        }
        Height = height;
        Width = width;
    }

    public int area()
    {
       return Height * Width;
    }
}

DDD'ye klasik yaklaşım, ne pahasına olursa olsun Anemik ve Zengin Modellerden kaçınmayı belirtmez. Bununla birlikte, MDA yine de tüm DDD kavramlarını (sınırlı bağlamlar, bağlam eşlemeleri, değer nesneleri, vb.) Uygulayabilir ancak her durumda Anemic ve Rich modellerini kullanabilir. Bir dizi etki alanı kümesinde karmaşık Etki Alanı Kullanım Durumlarını düzenlemek için Etki Alanı Hizmetlerini kullanmanın, uygulama katmanından çağrılan kümelerden çok daha iyi bir yaklaşım olduğu birçok durum vardır. Klasik DDD yaklaşımından tek fark, tüm doğrulamaların ve iş kurallarının nerede yer aldığıdır? Model doğrulayıcılar olarak bilinen yeni bir yapı var. Doğrulayıcılar, herhangi bir kullanım durumu veya etki alanı iş akışı gerçekleşmeden önce tam girdi modelinin bütünlüğünü sağlar. Toplam kök ve alt varlıklar anemiktir, ancak her biri gerektiğinde kendi model doğrulayıcılarına sahip olabilir, kök doğrulayıcısı tarafından. Doğrulayıcılar hala SRP'ye bağlıdır, bakımı kolaydır ve birim test edilebilir.

Bu değişimin nedeni, şimdi Mikro Hizmetlere yönelik bir UX ilk yaklaşımı yerine önce API'ye doğru ilerlememizdir. REST bunda çok önemli bir rol oynadı. Geleneksel API yaklaşımı (SOAP nedeniyle) başlangıçta komut tabanlı API'ye karşı HTTP fiillerine (POST, PUT, PATCH, GET ve DELETE) sabitlendi. Komut tabanlı bir API, Zengin Model nesne yönelimli yaklaşıma iyi uyum sağlar ve hala çok geçerlidir. Bununla birlikte, basit CRUD tabanlı API'ler, Zengin bir Model içine sığabilmelerine rağmen, geri kalanını düzenlemek için basit anemik modeller, doğrulayıcılar ve Etki Alanı Hizmetleri ile çok daha uygundur.

DDD'yi sunduğu her şeyde seviyorum, ancak sürekli değişen ve mimariye daha iyi yaklaşmak için onu biraz uzatmanız gereken bir zaman geliyor.