실체의 단일 책임 (변경 이유)은 자신을 고유하게 식별해야하며, 다시 말해서 책임을 찾을 수 있어야한다.
에릭 에반의 DDD 서적, 페이지. 93 :
엔티티의 가장 기본적인 책임은 행동을 명확하고 예측할 수 있도록 연속성을 설정하는 것입니다. 그들은 여분을 유지하면 최선을 다합니다. 속성이나 동작에 중점을 두지 않고 Entity 오브젝트의 정의를 가장 본질적인 특성, 특히이를 식별하거나 찾거나 일치시키는 데 주로 사용되는 특성으로 분류하십시오. 해당 동작에 필요한 개념 및 속성에 필수적인 동작 만 추가하십시오.
그 외에도 핵심 개체와 관련된 다른 개체의 동작과 특성을 제거하려고합니다. 개체 문제 외에도, 개체는 소유 한 개체의 작업을 조정하여 책임을 수행하는 경향이 있습니다.
1.
... ENTITY 객체의 정의를 가장 본질적인 특성, 특히이를 식별하거나 찾거나 일치시키는 데 주로 사용되는 특성으로 분류하십시오. 개념에 필수적인 행동 만 추가하십시오 ...
엔터티 에 고유 한 ID 가 할당 되면 해당 엔터티 가 설정되므로 해당 엔터티가 해당 아이덴티티 를 유지 하거나 자신을 식별 하는 데 아무런 동작이 필요하지 않다고 가정 합니다 . 따라서 저자 가 " 개념에 필수적인 행동 "으로 어떤 행동을 언급하고 있는지 ( find그리고 match 운영 외에 ) 이해하지 못하는가 ?
2.
... ENTITY 객체의 정의를 가장 본질적인 특성, 특히이를 식별하거나 찾거나 일치시키는 데 주로 사용되는 특성으로 분류하십시오. 그 외에도 핵심 ENTITY와 관련된 다른 개체의 동작과 특성을 제거하십시오.
따라서 개체를 식별하는 데 도움이되지 않는 모든 동작은 여전히 해당 동작 을 해당 개체 의 본질적인 특성으로 특성화 합니다 (즉, 짖는 소리는 개에게는 고유하고, 비행은 비행기에는 고유하고, 알을 낳는 것은 조류에 고유합니다.) ), 해당 개체와 관련된 다른 개체에 넣어야합니까 (예 : 개 개체와 관련된 개체에 짖는 동작을 넣어야합니까?)
삼.
그 외에도 핵심 ENTITY와 관련된 다른 개체의 동작과 특성을 제거하십시오.
A) MyEntity대표의 책임 A_resp과 B_resp객체 a와 b각각.
대부분의에도 불구 A_resp하고 B_resp작업이 수행됩니다 a와 b경우, 클라이언트는 여전히 제공됩니다 A_resp과 B_resp를 통해 MyEntity클라이언트의 관점에서 두 가지 책임에 속하는지, 어떤 수단 MyEntity. 따라서, 의미하지는 않습니다 MyEntity또한이있다 A_resp및 B_resp책임과 같은 위반 SRP를 ?
B)는 우리가 가정해도 A_resp과 B_resp에 속하지 않는 MyEntity, MyEntity여전히 책임이 AB_resp개체의 작업 조정의 a과 b. 그래서하지 않습니다 MyEntity위반 SRP를 최소로하기 때문에 그것은이 두 가지 책임 고유 또한 자신을 식별하고을을 - 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
{ ... }
최신 정보:
1.
이 문맥에서 동작은 의미 적 동작을 나타냅니다. 예를 들어, 클래스를 고유하게 식별하는 데 사용되는 클래스의 속성 (예 : 도메인 개체의 속성)에는 동작이 있습니다. 이것은 코드에서 직접 표현되지는 않습니다. 예상되는 동작은 해당 속성에 대한 중복 값이없는 것입니다.
따라서 코드에서 엔티티의 ID를 유지하는 동작 (즉, 작업)을 실제로 구현할 필요는 거의 없습니다. 엔티티), 그러나 우리가이 ID 속성을 코드로 변환 할 때, 그 의미론의 일부가 손실됩니다 (즉, ID 값을 고유하게 확인하는 부분이 손실 됨)?
2.
Furthmore, Age와 같은 속성은 Person 엔터티 외부에 컨텍스트가 없으므로 다른 객체로 이동하는 것이 의미가 없습니다 ... 그러나 그 정보는 고유 식별자와 다른 위치에 쉽게 저장 될 수 있습니다. 행동에 대한 혼란스러운 참조. 나이는 게으른로드 값일 수 있습니다.
a) Age속성이 게으르게로드 된 경우 의미 적 Age으로 속성 일지라도 동작이라고 부를 수 있습니까?
삼.
유효한 주소인지 확인하는 등 주소에 특정한 작업을 쉽게 수행 할 수 있습니다. 디자인 타임에 알지 못할 수도 있지만이 전체 개념은 객체를 가장 작은 부분으로 나누는 것입니다.
Age다른 객체로 이동 하여 컨텍스트를 잃어 버릴 것이라는 데 동의하지만 DateOfBirth속성을 다른 객체로 옮길 경우 컨텍스트가 손실되지 않지만 일반적으로 이동하지는 않습니다.
우리가 Address다른 물체로 옮긴 주된 이유는 무엇입니까 DateOfBirth? 때문에이 DateOfBirth더 본질적이고 Person실체 이하 기회가 있기 때문에 미래의 어딘가에서 우리는에 작업의 특정을 정의해야 할 수도 DateOfBirth?
4. 나는 아직도 여부를 알 수없는 말을해야 MyEntity또한 가지고 A_resp와 B_resp책임과 이유 MyEntity도 한 AB_resp위반으로 간주되지 않습니다 SRP
EULERFX
1)
작성자가 언급 한 동작은 엔터티와 관련된 동작입니다. 엔터티의 상태를 수정하는 동작입니다.
a) 내가 당신을 올바르게 이해한다면, 당신은 엔티티 가 그 속성 (즉, state ) 을 수정 하는 행동 만을 포함해야한다고 말하고 있습니까?
B) 그리고 무엇에 대해 행동을 반드시 수정하지 않는 엔티티의 상태를 하지만 여전히 것으로 간주 고유 그 특성 엔티티 (예 : 짖는 소리가 될 것이다 고유 의 특성 Dog이 수정하지 않은 경우에도 실체 개의 상태 )? 이러한 행동을 엔티티 에 포함시켜야합니까 아니면 다른 객체로 옮겨야합니까?
2)
행동을 다른 물체로 옮기는 한, 저자는 가치있는 물체를 구체적으로 언급하고 있습니다.
내 인용문에는 포함되어 있지 않지만 저자는 같은 단락에서 행동 (및 속성 )이 다른 엔티티 로 옮겨 질 것이라고 언급했습니다 ( 동작 을 VO 로 옮기면 얻을 수있는 이점을 이해하지만 )
3) 가정 MyEntity(질문 참조 3. 내 원래의 게시물을) 우리가 말할 것, SRP를 위반하지 않는 책임 의는 MyEntity또한 구성 다른 것들 중 하나입니다 :
ㅏ. A_resp + B_resp + AB_resp ( AB_resp객체를 조정 a하고 b)
또는
비. AB_resp + 위임 A_resp및 B_resp개체 ( a와 b)과 연관 MyEntity?
4) Eric Evan의 DDD 서적, pg. 94 :
CustomerID는 Customer ENTITY의 유일한 유일한 식별자이지만 (그림 5.5) 전화 번호와 주소는 종종 고객을 찾거나 일치시키는 데 사용됩니다. 이름은 개인의 신원을 정의하지 않지만, 종종 신원을 결정하는 수단의 일부로 사용됩니다.
이 예에서 전화 및 주소 속성은 고객으로 이동했지만 실제 프로젝트에서는 해당 선택이 도메인 고객이 일반적으로 일치하거나 구별되는 방식에 따라 다릅니다. 예를 들어, 고객에게 다른 목적으로 많은 연락처 전화 번호가있는 경우 전화 번호는 ID와 관련이 없으며 영업 담당자와 연락해야합니다.
ㅏ)
CustomerID는 Customer ENTITY의 유일한 유일한 식별자이지만 (그림 5.5) 전화 번호와 주소는 종종 고객을 찾거나 일치시키는 데 사용됩니다. 이름은 개인의 신원을 정의하지 않지만, 종종 신원을 결정하는 수단의 일부로 사용됩니다.
인용문은 정체성 과 관련된 속성 만 이 엔티티에 남아 있어야한다고 언급한다 . 저자는 엔티티 가이 엔티티 를 찾거나 일치시키는 데 자주 사용되는 속성 만 포함해야 하지만 다른 모든 속성 은 이동해야한다고 가정합니다.
b) 그러나 다른 속성 은 어떻게 / 어디로 옮겨야합니까? 예를 들어 (여기서 주소 속성 은 찾거나 일치 하는 데 사용되지 않으므로 주소 속성을 외부 Customer로 옮기고 싶다고 가정 ) :Customer
Customer.Address(유형 string) 대신 유형 의 속성 Customer.Address을 생성하는 Address경우 주소 속성 을 관련 VO 객체 (유형 Address)로 이동 했습니까? 아니면 Customer여전히 주소 속성이 포함되어 있다고 말 합니까?
씨)
이 예에서 전화 및 주소 속성은 고객으로 이동했지만 실제 프로젝트에서는 해당 선택이 도메인 고객이 일반적으로 일치하거나 구별되는 방식에 따라 다릅니다. 예를 들어, 고객에게 다른 목적으로 많은 연락처 전화 번호가있는 경우 전화 번호는 ID와 관련이 없으며 영업 담당자와 연락해야합니다.
우리 가 그 특정에 속하는 많은 연락처 전화 번호 를 각각 가정한다고 가정하면 ,이 전화 번호 는 전화 번호 가 하나 뿐 일 때 와 마찬가지로 신원 과 관련 이 있다고 말할 수 있기 때문에 여기에서 잘못된 저자 Customer가 아닙니다. ?CustomerCustomer
5)
저자가 엔티티를 제거한다고 제안하는 이유는 고객 엔티티를 처음 작성할 때 고객과 연관 될 것으로 생각할 수있는 속성으로 엔티티를 채우는 경향이 있기 때문입니다. 이것은 궁극적으로 빈혈 도메인 모델로 이어지는 행동을 간과하는 데이터 중심 접근 방식입니다.
주제 끄기,하지만 난 생각 빈혈 도메인 모델의 이동 결과를 행동을 에서 엔티티 귀하의 예제가 채우는 동안, 기업 의 많은 속성 을 초래할 것, Customer너무 많이 가지고 행동을 우리는 아마도에 포함 것 때문에 ( 행동 하는 이러한 추가 속성을 수정하여 SRP를 위반합니까?Customer
감사