2012-11-21 2 views
3

다른 집계에 속한 여러 엔터티에 공통된 동작이 있는데, 이는 추상 클래스를 고려해야합니다.다른 집계에있는 엔티티를 공통 클래스에서 상속받는 것이 좋습니까?

다른 집계의 엔터티에 공통 추상 클래스를 상속하는 데 단점이 있습니까?


사용하는 경우

여러 엔티티 이름, 설명 또는 다른 언어로 번역 될 수있는 다른 특성을 가지고있다.

예를 들어 setName(language, name)으로 이름을 지정하고 getName(language)으로 검색합니다. EntityNameEntity 집계 내에 주어진 Entity 클래스

class EntityName 
{ 
    protected Entity entity; 
    protected Language language; 
    protected String text; 
    protected int version; 

    public EntityName(Entity entity, Language language) 
    { 
     this.entity = entity; 
     this.language = language; 
     this.version = 1; 
    } 

    // setText(), getText(), ... 
} 

:

각 언어의 각 텍스트

같은 객체에 저장됩니다. EntitysetName()getName()을 통해 EntityName을 만들고 읽고 쓸 수 있습니다.

그러나 EntityName, EntityDescription, OtherEntityName과 같은 클래스는 모두 거의 동일한 코드를 공유합니다. 변경 사항보다 유일한 부분은 집계에 대한 참조이므로 생성자에 대한 참조입니다.

+0

아래 답변에 자유롭게 의견을 말하십시오. 불명확하거나 도움이되지 않는 부분이 있으면 답변을 조정할 수 있습니다. 감사! – btiernay

답변

4

이 주제에 대한 내용은 많지 않습니다. 그러나, 특히 How To: Domain Driven Design

을받을 자격이 문서를 보라 단원을 읽어 2 단계 - 골재와 골재 뿌리 확인 : 클래스 에서 고급 상황에서

, 다형성 (polymorphism)의 존재를 모델은 집계 경계에도 영향을 줄 수 있습니다. 이것은 당신이 부기 데이터를 저장하는 경우 여러 집계 루트 클래스 모두 동일한 기본 클래스

을 공유 할 때 적절한 도메인 모델 외부 (ID, 버전, 타임 스탬프, 업데이트 타임 스탬프를 생성)가 발생합니다 (예 : 귀하의 지속성 레이어를 지원하기 위해), 나는 이것을 문제로 보지 않습니다. 그러나 실제 비즈니스 메소드 및 속성을 재사용하려는 경우, 상속을 composition 또는 AOP 소개로 대체하는 것을 고려할 수 있습니다. 당신이 정말로 진정한 Liskov is-a 관계가 아니라 코드 재사용을 달성하려고하는 것처럼

업데이트

업데이트 된 사용 사례보고 후, 그것은 보인다. 일부 언어에서는 mixins (Groovy) 또는 traits (Scala)과 같은 개념으로 이러한 재사용 유형을 더 잘 지원합니다. 자바를 가정하면, 클래스를 생성하고 Project Lombok의 @Delegate 주석을 사용하여 구현에 전달할 수 있습니다.이것은 다음과 같은 장점이 있습니다

  • 당신이 진정한 위해 하나의 상속 옵션을 저장할 수 있습니다 souce에 모든 중복없이 당신을위한 바이트 코드를 생성 집계 encapulation의 동일한 수준을 제공됩니다-A 미래
  • 에서 관계는 내가이 순수한 생각하는 도메인

에 걸쳐 일관성을 보장하고 모델의 유연성을 가능하게한다. 나는 Project Lombok을 몇 가지 프로젝트에 사용하여 큰 성공을 거뒀습니다. Java에서 누락 된 언어 기능을 단계적으로 수행하고 특정 관용구를 구현하는 데 필요한 상용구 코드보다 도메인에 더 집중할 수 있습니다.

+0

답변 해 주셔서 감사합니다. 공통적 인 동작을 공유하는 집계가 아니라 집계 내의 엔터티입니다. 유스 케이스로 내 질문을 업데이트했습니다. – Benjamin

+0

@Benjamin 설명해 주셔서 감사합니다. 나는 당신의 유스 케이스를 반영하려고 내 대답을 업데이트했다. – btiernay

+1

저는 실제로 특성을 지원하는 PHP를 사용하고 있습니다. 그래서 공통된 추상 클래스를 사용하는 것보다 더 깨끗한 접근 방식이 될 수 있습니다. 감사합니다! – Benjamin

1

일반적인 정의가 집계 루트 디자인에 영향을주지 않는 한 괜찮습니다. 즉, 집계 루트를 모델링하고 공통점이 많다는 것을 알기 때문에 공통 기본 클래스를 추출합니다.

다른 경계 된 컨텍스트에서 뿌리를 뭉치 게하는 공통점이 너무 많으므로이 점에 대해 두 번 생각할 것입니다. 그것은 약간의 코드 냄새가 IMO입니다.

+0

답변 해 주셔서 감사합니다. 공통적 인 동작을 공유하는 집계가 아니라 집계 내의 엔터티입니다. 유스 케이스로 내 질문을 업데이트했습니다. – Benjamin

+0

Entity 인 Aggregate Root를 언급 한 것과 같은 anwser입니다. – MikeSW

0

올바른 상속은 is-a 관계로 정의됩니다. 거기에는 뿌리를 모으는 데 적용되는 경우는 거의 없습니다.

뿌리가 비슷해 보이는 것이 그들이 같은 장소에서 왔음을 의미하지는 않습니다.

도메인에서 의미있는 이름으로 기본 클래스를 만들 수 있다면 계속 진행하십시오. 그렇지 않다면하지 마십시오.

관련 문제