Etki Alanı Varlığı Tek Sorumluluk İlkesini ihlal ediyor mu?

Bir işletmenin tek sorumluluğu (değişim nedeni), kendisini benzersiz bir şekilde tanımlamak, diğer bir deyişle sorumluluğunun anlaşılabilir olması olmalıdır.

Eric Evan'ın DDD kitabı, sf. 93:

İşletmelerin en temel sorumluluğu, davranışın açık ve öngörülebilir olabilmesi için süreklilik sağlamaktır. Yedek tutulursa bunu en iyi şekilde yaparlar. Özniteliklere ve hatta davranışa odaklanmak yerine, Entity nesnesinin tanımını en içkin özelliklere, özellikle onu tanımlayan veya bulmak veya eşleştirmek için yaygın olarak kullanılan karakterlere ayırın. Yalnızca bu davranış için gerekli olan kavram ve öznitelikler için gerekli olan davranışı ekleyin.

Bunun ötesinde, temel Varlık ile ilişkili diğer nesnelere davranış ve nitelikleri kaldırmaya bakın. Kimlik sorunlarının ötesinde, Varlıklar sahip oldukları nesnelerin işlemlerini koordine ederek sorumluluklarını yerine getirme eğilimindedir.

1.

... ENTITY nesnesinin tanımını, özellikle onu tanımlayan ya da onu bulmak ya da eşleştirmek için yaygın olarak kullanılanlar olmak üzere, en içsel özelliklere ayırın. Yalnızca kavram için gerekli olan davranışı ekleyin ...

Bir varlığa benzersiz bir kimlik atandığında , kimliği oluşturulur ve bu nedenle böyle bir varlığın kimliğini korumak veya kendini tanımlamasına yardımcı olmak için herhangi bir davranışa ihtiyaç duymadığını varsayarım . Böylece, ben ne tür davranışların yazar (yanında atıfta olduğunu anlamıyorum findve match operasyonlar ) "ile kavramına esastır davranışı "?

2.

... ENTITY nesnesinin tanımını, özellikle onu tanımlayan ya da onu bulmak ya da eşleştirmek için yaygın olarak kullanılanlar olmak üzere, en içsel özelliklere ayırın. ... Bunun ötesinde, çekirdek ENTITY ile ilişkili diğer nesnelere ilişkin davranış ve nitelikleri kaldırmaya bakın.

Yani varlığı tanımlamaya yardımcı olmayan herhangi bir davranış, ama biz yine de bu davranışı o varlığın kendine özgü bir özelliği olarak nitelendiririz (yani havlama köpeklere özgüdür, uçmak uçaklara özgüdür, yumurtlamak kuşlara özgüdür. .), bu varlıkla ilişkili diğer nesnelere konulmalıdır (örnek: havlayan davranışı bir köpek varlığıyla ilişkili bir nesneye koymalıyız)?

3.

Bunun ötesinde, çekirdek ENTITY ile ilişkili diğer nesnelere yönelik davranış ve nitelikleri kaldırmaya bakın.

a) MyEntitydelegeler sorumlulukları A_respve B_respnesnelere ave bsırasıyla.

Çoğu rağmen A_respve B_respçalışma yapılır ave börneklerini, müşteriler hala servis edilir A_respve B_respiçinden MyEntitymüşterinin bakış açısından iki sorumlulukları ait olduğunu, hangi araçlar MyEntity. Böylece, ortalama etmediğini MyEntityde vardır A_respve B_respsorumluluklar ve bu şekilde ihlal SRP ?

b) Bunu varsaysak A_respve B_respait olmasak bile MyEntity, MyEntityhala AB_respnesnelerin ave operasyonlarının koordinasyonundan sorumludur b. Yani SRP'yiMyEntity ihlal etmiyor çünkü en azından iki sorumluluğu var - kendini benzersiz olarak tanımlamak ve ayrıca ?AB_resp

class MyEntity
{
    private A a = ...
    private B b = ...


    public A GetA()
    { ... }

    public B GetB()
    { ... }

    /* coordinates operations of objects a and b */
    public int AworkB()
    { ... }
}

/* A encapsulates a single responsibility resp_A*/
/* A is value object */
class A
{ ... }

/* B encapsulates a single responsibility resp_B*/
/* B is value object */
class B
{ ... }

GÜNCELLEME:

1.

Bu bağlamdaki davranış semantik davranışa atıfta bulunmaktadır. Örneğin, bir sınıftaki bir özelliğinin (yani bir etki alanı nesnesindeki özniteliğin) benzersiz bir şekilde tanımlanması için kullanılan bir davranışı vardır. Bu doğrudan kodda temsil edilmese de. Beklenen davranış, söz konusu özellik için yinelenen değerlerin olmamasıdır.

Bu nedenle, kodda, neredeyse hiçbir zaman gerçekte varlığın kimliğini koruyacak bir davranış (yani bir işlem) uygulamamız gerekmeyecektir, çünkü böyle bir davranışın yalnızca bir etki alanı modelinde (ID özniteliği şeklinde) ancak bu kimlik niteliğini koda çevirdiğimizde, anlambiliminin bir kısmı kaybolur (yani, kimlik değerinin benzersiz olduğundan dolaylı olarak emin olunan kısım kaybolur)?

2.

Ayrıca, Yaş gibi bir mülkün bir Kişi Varlığı dışında bir bağlamı yoktur ve bu nedenle, farklı bir nesneye taşınmak mantıklı değildir ... Ancak bu bilgiler, benzersiz tanımlayıcının ayrı bir yerde kolayca saklanabilir, dolayısıyla davranışa kafa karıştırıcı referans. Yaş tembel bir yük değeri olabilir.

a) AgeÖzellik tembel yüklüyse, anlamsal Ageolarak sadece bir özellik olsa da, buna bir davranış diyebiliriz ?

3.

Adrese özgü, geçerli bir adres olduğunu doğrulama gibi işlemleri kolayca yapabilirsiniz. Bunu tasarım zamanında bilmiyor olabilirsiniz, ancak tüm bu kavram nesneleri en küçük parçalarına ayırmaktır

AgeFarklı bir nesneye geçerek bağlamı kaybedeceğimizi kabul etsem de , DateOfBirthmülkü farklı bir nesneye taşırsak bağlam kaybolmaz , ancak genellikle onu taşımayız.

AddressBaşka bir nesneye taşınmamızın ana nedeni nedir, değil DateOfBirthmi? Çünkü varlık DateOfBirthiçin daha içsel Personya da gelecekte bir yerde belirli operasyonları tanımlamamız gerekebileceğimiz için daha az şans var DateOfBirthmı?

4. Ben hala bilmiyorum söylemeliyim MyEntityda vardır A_respve B_respsorumlulukları ve neden MyEntityde sahip AB_respihlali olarak kabul edilmez SRP

EULERFX

1)

Yazarın bahsettiği davranışlar, varlıkla ilişkili davranışlardır. Bunlar, varlığın durumunu değiştiren davranışlardır

a) Sizi doğru anlarsam, varlığın yalnızca niteliklerini değiştiren davranışları (yani durumunu ) içermesi gerektiğini mi söylüyorsunuz ?

b) Ve varlığın durumunu değiştirmesi zorunlu olmayan , ancak yine de o varlığın içsel bir özelliği olduğu düşünülen davranışlar hakkında (örnek: havlama , bir varlığın değişmemiş olsa bile içsel bir özelliği olacaktır) Köpeğin durumu )? Bu davranışları bir varlığa dahil etmeli miyiz yoksa başka nesnelere mi taşınmalı? Dog

2)

Davranışı diğer nesnelere taşıma konusunda, yazar özellikle değer nesnelerine atıfta bulunmaktadır.

Alıntımda yer almasa da, yazar aynı paragrafta bazı durumlarda davranışların (ve niteliklerin ) diğer varlıklara da taşınacağından bahsediyor (ancak davranışları VO'lara taşımanın faydalarını anlıyorum )

3) varsayarsak MyEntity(soruya bakın 3. benim orijinal sonrası) biz demek olur, SRP ihlal etmez sorumluluk ait MyEntityayrıca oluşan diğer şeyler arasında yer alıyor:

a. A_resp + B_resp + AB_resp ( AB_respnesneleri koordine eder ave b)

veya

b. AB_resp + temsilci seçme A_respve ilişkili B_respnesnelere ( ave b) MyEntity?

4) Eric Evan'ın DDD kitabı, s. 94:

CustomerID, Müşteri ENTITY ürününün tek ve tek tanımlayıcısıdır (şekil 5.5), ancak bir Müşteri bulmak veya eşleştirmek için genellikle telefon numarası ve adres kullanılır. İsim, bir kişinin kimliğini tanımlamaz, ancak genellikle onu belirleme yollarının bir parçası olarak kullanılır.

Bu örnekte, telefon ve adres özellikleri Müşteri'ye taşındı, ancak gerçek bir projede bu seçim, alan adının müşterilerinin tipik olarak nasıl eşleştirildiğine veya ayırt edildiğine bağlı olacaktır. Örneğin, Müşterinin farklı amaçlarla birçok kişi telefon numarası varsa, telefon numarası kimlikle ilişkilendirilmez ve Satış Kişisi'nde kalmalıdır.

a)

CustomerID, Müşteri ENTITY ürününün tek ve tek tanımlayıcısıdır (şekil 5.5), ancak bir Müşteri bulmak veya eşleştirmek için genellikle telefon numarası ve adres kullanılır. İsim, bir kişinin kimliğini tanımlamaz, ancak genellikle onu belirleme yollarının bir parçası olarak kullanılır.

Alıntı, yalnızca kimlikle ilişkili niteliklerin bir varlıkta kalması gerektiğini belirtir . O yazar araçlarını varsayalım varlık sadece bu içermelidir özelliklerini sıklıkla kullanılır bulabilir veya maç bu varlık TÜM diğeri ise, nitelikleri taşınmış olmalıdır?

b) Peki diğer özellikler nasıl / nereye taşınmalı? Örneğin (Buradaki varsayım yani adres niteliği için kullanılmaz bulmak veya maç Customer ve böylece biz taşımak istediğiniz adresi özelliğini dışına Customer):

eğer yerine sahip Customer.Address(Çeşidi string) bir özellik oluşturmak Customer.AddressÇeşidi Addressbiz hareket etmedi, adresi özelliğini (tipidir ilişkili VO nesnesine Address) ya da biz söyleyebilirim Customerhala içeren adres niteliğini ?

c)

Bu örnekte, telefon ve adres özellikleri Müşteri'ye taşındı, ancak gerçek bir projede bu seçim, alan adının müşterilerinin tipik olarak nasıl eşleştirildiğine veya ayırt edildiğine bağlı olacaktır. Örneğin, Müşterinin farklı amaçlarla birçok kişi telefon numarası varsa, telefon numarası kimlikle ilişkilendirilmez ve Satış Kişisi'nde kalmalıdır.

Birçok her varsayarsak, çünkü burada haksız yazar değil mi irtibat numaralarınıCustomer yalnızca o belirli aittir vardır Customer, o zaman ben bu derdim telefon numaraları ile ilişkili kimlik tıpkı olduğu gibi Customersadece vardı bir telefon numarası ?

5)

Yazarın varlığı kaldırmayı önermesinin nedeni, başlangıçta bir Müşteri varlığı oluşturduğunda, onu bir müşteriyle ilişkilendirmeyi düşünebileceği herhangi bir nitelikle doldurma eğilimi olmasıdır. Bu, nihayetinde anemik etki alanı modeline yol açan davranışları gözden geçiren veri merkezli bir yaklaşımdır.

Konu dışı ama düşündüm anemik alanı modeli hareketli sonuçları davranışlarını bir takım varlık senin örneğin bir doldurma iken, varlık ve birçok niteliklerini neden olacaktır, Customerçok fazla sahip davranışı muhtemelen de dahil ediyorum çünkü ( davranışların hangi bu ek özellikleri değiştirebilir ) ve böylece SRP'yi ihlal ediyor musunuz?Customer

Teşekkürler

Bu bağlamdaki davranış semantik davranışa atıfta bulunmaktadır. Örneğin, bir sınıftaki bir özelliğinin (yani bir etki alanı nesnesindeki özniteliğin) benzersiz bir şekilde tanımlanması için kullanılan bir davranışı vardır. Bu doğrudan kodda temsil edilmese de. Beklenen davranış , söz konusu özellik için yinelenen değerlerin olmamasıdır. Kendi kimliğine sahip olabilen, ancak bir Kişi Varlığının bağlamı dışında var olmayan bir Adres gibi bir şey yine de kendi nesnesine taşınmalıdır. Böylece Varlığı Toplam Kök haline getirme.

Dahası, Yaş gibi bir mülkün bir Kişi Varlığı dışında bir bağlamı yoktur ve bu nedenle farklı bir nesneye taşınmak mantıklı değildir. Bağlam kaybolur ve bu nedenle bunun Kişi Varlığı için gerekli olan bir değer olduğunu güvenle belirleyebilirsiniz. Aksi takdirde değeri bulamadınız. Ancak bu bilgiler, benzersiz tanımlayıcının ayrı bir yerde, dolayısıyla davranışa kafa karıştırıcı referansta kolayca saklanabilir . Yaş tembel bir yük değeri olabilir.

Sorunuzu cevaplamak için. Hayır, Tek Sorumluluk İlkesini ihlal etmez. Bir Kişinin, daha karmaşık ve bir kişiyle ilgili olan Adres gibi bir şeyin değil, yalnızca kişi eşyalarına sahip olması gerektiğini belirtmek, kendi varlığı olarak var olmalıdır.

Adrese özgü, geçerli bir adres olduğunu doğrulama gibi işlemleri kolayca yapabilirsiniz. Tasarım zamanında bunu bilmiyor olabilirsiniz, ancak tüm bu kavram, nesneleri en küçük parçalarına ayırmaktır, böylece böyle bir şey, gerçekten sonra yapıldığında nispeten basittir.

Güncelleme: 1) Çoğu durumda bu kimlik doğrulaması, bir nesneyi bir veri deposuna kaydettikten sonra yapılır. Bu, varlık doğrulamasını temsil eden kodun var olduğu, ancak başka bir yerde var olduğu anlamına gelir. Genellikle kimlik değerini vermekle yükümlü olan kodda bulunur. Bu yüzden tekliğin doğrudan varlık kodunda temsil edilmediğini belirtiyorum .

2) Doğru ifade Age, davranışı olan bir niteliktir. Bu mülkü tüketen bir geliştiricinin o mülkü nasıl kullanacağına dair doğru bir karar verebilmesi için Yaş'ın tembel olarak yüklendiğini belgelemeniz gerekir.

3) DateOfBirthgenellikle farklı bir nesnedir; Üzerinde önceden tanımlanmış işlemler bulunan bir tarih nesnesi. Bazı dillerde date nesnesinin üzerinde zaten tanımlanmış bir etki alanı modeli vardır. Örneğin c # 'da saat dilimini belirtebilirsiniz, tarih UTC ise, zaman aralığı almak için tarih ekleyin ve çıkarın. Dolayısıyla, hareket etme varsayımınız DateOfBirthdoğru olacaktır.

4) MyEntityYapan tek şey yetki devri ve koordinasyon ise hayır SRP'yi ihlal etmez. Tek sorumluluğu delege etmek ve koordine etmektir ve Cephe kalıbı olarak adlandırılır

Çok güzel bir soru. SRP bu kadar litre olarak alınmamalıdır. Tanımlama / arama, SRP ile ilgili olarak işletmenin sorumluluğunda değildir. Bir başkası ona bir kimlik (mağaza) vermek ve onu aramaktan (yani Depo ) sorumludur .

Bir varlığın temel amacı, model tarafından ortaya çıkarılan kavramları temsil etmektir. Bir Varlık ile Değer Nesnesi arasındaki tek fark, Varlığın tanımlayıcı olmayan özelliklerinin ötesinde bir anlama sahip olmasıdır. Örneğin, bir Kişi Adını değiştirirse, sadece farklı bir adla aynı kişidir.

TL; DR: Bunu düşünmek üzeresiniz. Ancak, seninle birlikte düşünmek eğlendim. Yani tokalaş ....

Bir işletmenin tek sorumluluğu (değişim nedeni), kendisini benzersiz bir şekilde tanımlamak, diğer bir deyişle sorumluluğunun anlaşılabilir olması olmalıdır.

Hayır, bu doğru değil. Bir işletmenin tek sorumluluğu sürekliliktir.

Kimlik, sürekliliğin ortaya çıkan bir sonucudur. Kimliğin ayrılabilir bir fikir olarak modellenmesi performans optimizasyonudur.

İşte bir örnek: Bir kullanıcının patronu vale için araba. Bir saat sonra, bir restoran patronu araba ister. Vale vermeli mi?

Eğer patron "aynı" ise vale araba vermek gerektiğini söylemek kolaydır. Ama bu gerçekten ne anlama geliyor? Bunu belirlemenin doğru yolu, "şimdi" kullanıcısıyla başlamak ve o arabanın valeya verilmesinin o tarihin bir parçası olup olmadığını görmek için bu kullanıcının geçmişinde geriye doğru arama yapmaktır.

Elbette bunu yapamayız. Kendi tarihimizi tam olarak takip etmekte zorlanıyoruz, sürekli bizimle birlikte olmayan bir şeyin tarihine aldırmayın. Yani hamilinin tarihini kullanmak yerine kısa yollara gidiyoruz. Kullanıcı, şu anda anahtarlara bağlı etiketle aynı numaraya sahip bilet koçasına sahip mi? Kullanıcının cüzdanındaki sürücü belgesi DMV'deki başlıktaki adla eşleşiyor mu, sürücü belgesindeki resim kullanıcının yüzüne benziyor mu? Vb.

Kısacası: kullanıcı geçmişini kontrol etmek yerine, mevcut durumun arabanın gelişi ile dönüş talebi arasındaki süreyi kapsayan bir tarihle tutarlı olup olmadığını görmek için kullanıcının mevcut durumunu kontrol ediyoruz.

Varlıkları modellerken, benzer bir optimizasyon kullanıyoruz. Tüm kuruluşlara ortak sorumluluklar veriyoruz.

1. Geçmişin başlangıcının, nesnenin durumuna değiştirilemez bir tanımlayıcı ataması içermesini sağlamak
2. Bir sonraki durumun her zaman önceki durumun tanımlayıcısının sadık bir kopyasını içermesini sağlamak.

Burada varlığın ikinci bir sorumluluğunu tanımlamıyorum; varlık süreklilikten hala sorumludur - tarihin tutarlı bir anlatı olduğundan emin olmak. Tanımlayıcı sorumlulukları, yalnızca tüm varlıklar için ortak olan bir alt kümedir.

Henüz benzersizliği uygulayabildik. Tek bir varlıkta bu mümkün değildir, çünkü teklik tüm varlıkların durumuna erişim gerektirir; burada tek bir varlığın yalnızca kendi varlığına erişimi vardır.

Bir kez daha, tüm tanımlayıcıları her seferinde kontrol etmek pratik değildir, bunun yerine benzersizliği kolay bir şekilde tatmin ederiz: Bir sonraki tanımlayıcıyı oluşturan kod asla tekrarlanmamalıdır.

Sonunda, bu, bellekte iki farklı durum parçasının denkliğini test ederek sürekliliği doğrulayabildiğimiz anlamına gelir ve çevrimsel olmayan grafikleri sorgulamaya çalışırken çok fazla zahmetten tasarruf eder.

Ayrıca Tek Sorumluluk İlkesini (gerçekten iyi bir fikir) bir atomik sorumluluk ilkesiyle karıştırmış görünüyorsunuz. Bir sorumluluğu daha küçük, daha kolay yönetilen parçalara ayırmak SRP ile uyumludur.

Bir varlığa benzersiz bir kimlik atandığında, kimliği oluşturulur ve bu nedenle böyle bir varlığın kimliğini korumak veya kendini tanımlamasına yardımcı olmak için herhangi bir davranışa ihtiyaç duymadığını varsayarım. Bu nedenle, yazarın "kavram için gerekli olan davranış" ile (bul ve eşleştir işlemlerinin yanı sıra) ne tür bir davranıştan bahsettiğini anlamıyorum?

Kimlik belirlenirse, evet, işletmenin tanımlanması için başka bir şeye ihtiyacı yoktur. Yazarın bahsettiği davranışlar, varlıkla ilişkili davranışlardır. Bunlar, varlığın durumunu değiştiren davranışlardır. Örneğin, bir Customervarlığın bir MakePreferreddavranışı olabilir . Yazarın varlığı kaldırmayı önermesinin nedeni, başlangıçta bir Customervarlık oluşturduğunda , onu bir müşteriyle ilişkilendirmeyi düşünebileceği herhangi bir nitelikle doldurma eğilimi olmasıdır. Bu, nihayetinde anemik etki alanı modeline yol açan davranışları gözden geçiren veri merkezli bir yaklaşımdır.

Davranışı diğer nesnelere taşıma konusunda, yazar özellikle değer nesnelerine atıfta bulunmaktadır. Davranışları VO'lara taşımanın iyi bir fikir olmasının nedeni, VO'ların genellikle varlıklardan daha "küçük" olmaları ve dolayısıyla daha odaklanmış olmalarıdır. Dahası, değişmezlik ve işlemlerin kapatılması gibi yönler, kod hakkında akıl yürütmeyi kolaylaştırırken, kodu daha katı hale getirir .

VO'larla birlikte bir işletme, davranışını uygulayan çeşitli VO'ları koordine eden bir çeşit çapa görevi görür.

SRP ile ilgili olarak, karışıklığınız garanti edilmez. Varlıkların stereotipik OOP uygulamasıyla ilgili bir sorun, kimlik ve devletin birleşmesidir. Gerçekten de davranışsal bir bakış açısıyla kimliğin davranışlarla hiçbir ilgisi yoktur. Başka bir deyişle, bir varlığın kimliği davranışlarının hiçbirini gerektirmez. Bu birleşmenin ortadan kaldırıldığı, AggregateSource veya burada tarif ettiğim fonksiyonel bir yaklaşım gibi uygulamalar var .

Diğer sorun, bir dereceye kadar, SRP'nin niteliksel bir önlem olabileceğidir. Herkes, bazı sınıfların ihlal ettiği tek bir sorumluluk tanımı yapabilir. İşletmenin sorumluluğunun, o işletmenin gerekli davranışlarını uygulamak olduğunu söyleyebiliriz. Bu anlamda tek bir sorumluluğu var. Ayrıca, bir işletme davranışları kurucu VO'lara devrettiğinde, SRP'yi ihlal etmez. SRP, türün bileşimini yasaklamaz. Nesneler arasındaki bağlantıyı mutlak minimum düzeye indirmeye, arayüzleri mümkün olduğunca çıplak tutmaya vb.

GÜNCELLEME

a) Sizi doğru anlarsam, varlığın yalnızca niteliklerini değiştiren davranışları (yani durumunu) içermesi gerektiğini mi söylüyorsunuz?

Evet, istisnalar olsa da ...

b) Ve varlığın durumunu değiştirmesi gerekmeyen, ancak yine de o varlığın kendine özgü bir özelliği olarak kabul edilen davranışlara ne dersiniz (örnek: havlama, bir Köpek varlığının kendine özgü bir özelliği olacaktır, olmasa bile) Köpek durumunu değiştirmek)? Bu davranışları bir varlığa dahil etmeli miyiz yoksa başka nesnelere mi taşınmalı?

Varlık örnekleri oluşturmak için fabrika yöntemlerini içermesi, varlıkların etkin bir şekilde alt varlıklar olduğu, ancak nesne referanslarının geçiş için kullanılmadığı durumlarda, varlıkların kabul edilebilir olması. Bu durumda, alt kuruluşun başvuru hizmeti tarafından kalıcı olması gerekir. Uygulama hizmeti, alt varlığı oluşturmak için üst varlığı kullanır.

3) MyEntity'in (orijinal yazımda 3. soruya bakın) SRP'yi ihlal etmediğini varsayarsak, MyEntity'nin bir sorumluluğunun aşağıdakilerden de oluştuğunu söyleyebilir miyiz:

Sorumluluğa uygulama perspektifinden bakıyorsunuz. Bunun yerine, varlığı sorumlulukları olan bir tür kara kutu olarak düşünün. Bunları nasıl ele aldığı, dışarıdan bakan biri olarak ilginizi çekmez. Sorumlulukların VO'lar ve hatta diğer kuruluşlar arasında bölünmesi bir uygulama konusudur.

Alıntı, yalnızca kimlikle ilişkili niteliklerin bir varlıkta kalması gerektiğini belirtir. Yazar TÜM diğer öznitelikler taşınması gerekirken, varlık sadece bu varlığı bulmak veya eşleştirmek için kullanılan öznitelikleri içermesi anlamına gelir varsayalım?

Daha spesifik olarak, davranış veya arama için gerekli olmayan özellikler varlığın bir parçası olmamalıdır. Neden rahatsız oluyorsun? Dahası, okuma modeli modeli gibi bir şeyle , varlıkların davranış için gerekli olan özelliklerin ötesinde bir şeye ihtiyaçları yoktur.

Customer.Address (type string türünde) yerine Address (Type) türünde bir özellik oluştururuz, address özniteliğini ilişkili bir VO nesnesine (Address türünde olan) taşıdık mı yoksa Müşterinin hala adres içerdiğini söyleyebilir miyiz? nitelik?

Evet, aslında, bir dize adresi ile Adres VO adresi arasında fark yoktur.

Burada yanlış yazar değil, çünkü Müşterinin yalnızca belirli bir Müşteriye ait olduğu birçok iletişim telefon numarasının her birini varsayarsak, bu telefon numaralarının tıpkı Müşterinin sahip olduğu kadar kimlikle ilişkili olduğunu söyleyebilirim bir telefon numarası?

Yazarın niyetinde% 100 değilim, ama sadece varlık arama gereksinimlerinin varlık ve karşılık gelen VO'ların yapıları nasıl değiştirebileceğini anlatıyor.

Konu dışı, ancak örneğinizin çok fazla özelliğe sahip bir varlığı doldururken anemik alan modelinin davranışı bir varlıktan çıkarmasından kaynaklandığını düşündüm. bu ek nitelikleri değiştiren davranışlar) ve dolayısıyla SRP'yi ihlal eden

Birçok özellik çok fazla davranış anlamına gelmez. Aslında, genellikle tam tersini gösterir. Getters ve setters ile çok sayıda özellik, ancak kapsülleyici davranış yok.

Peki, nasıl bakmak istediğinize bağlı.

Başka bir yol: "Tek Sorumluluk İlkesi Etki Alanı Varlığını ihlal ediyor mu?"

Her ikisi de yönergelerdir. Yazılım tasarımının hiçbir yerinde "ilke" yoktur. Bununla birlikte, iyi tasarımlar ve kötü tasarımlar vardır. Her iki kavram da iyi bir tasarım elde etmek için farklı şekillerde kullanılabilir.