DDD / OOP에서 엔티티의 잘 알려진 비즈니스 ID를 전용 유형으로 표시해야합니까?

9

실제로는 다른 기본 유형에 대해 사용자 정의 (불변) class를 사용하는 것을 의미 string합니다.

예 :

출판 : 국제 표준 도서 번호.
금융 : 국제 증권 식별 번호.

장점 :

식별자의 형식을 보장 할 수 있습니다.
모델의 일류 회원이됩니다.

단점 :

지속성 마찰을 추가합니다 (예 : Entity Framework).
더 많은 코드.

— 굴
소스

커스텀 클래스를 사용해야합니까? 확실한. ID로 사용해야합니까? 절대적으로 아님 :) 사업상의 의미가있는 ID는 문제가 발생할 수 있습니다.

— Songo

2

@Songo 나에게 그것은 ID에 가치 의미론이 있어야한다는 주장 이지만, 원시적 유형이 가치 의미론을 가진 유일한 유형이 아니기 때문에 클래스 imo를 배제 할 필요는 없습니다. 그 점을 잊어 버렸으므로 경쟁 답변을 자유롭게 게시하십시오.

— Ixrec

1

내 오래된 질문이 다른 의견을 가진 주제에 대해 언급했습니다 : programmers.stackexchange.com/questions/281827/… 나는 유형을 만들고 계속 그렇게했습니다.

— Ziv

6

문자열이 아닌 추가 복잡성을 정당화하기에 충분한 유용한 기능을 클래스에 제공 할 수 있다면 그렇게하십시오. ISBN 및 ISIN과 같은 식별자의 경우에는 그렇지 않습니다.

식별자 클래스가 유용하기 위해서는 다음과 같이 보일 것으로 기대됩니다.

class ISIN {
    fromCUSIP()
    fromRawISINString()
    toString(ISIN::FormatType)
    getExchange()
    getCountryCode()
    getLastFourDigits()
    getWhateverCode()
    ...
}

대신 다음과 같이 보입니다.

class ISIN {
    getString()
    setString()
}

그런 다음 클래스를 완전히 버리고 모든 곳에서 일반 문자열을 사용하고 모든 관련 변수 이름에 "isin"을 일관되게 사용해야합니다.

일부 언어의 경우 일반 프로그램에서 새 유형을 추가해도 "복잡함이 추가되지"않습니다.이 경우 기능이 전혀없는 경우에도 새 유형을 작성하는 것이 좋습니다. 그러나 C ++과 같은 대부분의 전통적인 OOP 언어에는 해당되지 않습니다.

— 익 렉스
소스

6

나는 그것을 갈 것이라고 말할 것입니다. 나는이 경우 장점이 단점보다 크다고 주장한다. 여분의 코드는 거의 최소화 될 수 있으며 지속성 문제는 새 클래스와 데이터베이스가 기대하는 유형 사이에 일종의 변환기를 제공하여 쉽게 쉽게 해결할 수 있습니다 (Entity Framework를 사용한 적이 없지만 상대적으로 고통스럽지 않습니다. 최대 절전 모드).

자신의 클래스를 정의하여 얻을 수있는 장점 중 하나는 컴파일러 에서 잘못된 값을 전달하려고하면 컴파일 타임에 ISBN 또는 ISIN을 원하는 모든 메소드가 알 수 있다는 것 입니다. 또한 엔터티에서 해당 필드를 실수로 덮어 쓰는 것이 훨씬 어렵습니다. 다음과 같은 일반적인 오류를 완전히 피할 수 있습니다.

book.setAuthor(otherBook.getAuthorName());
book.setIsbn(otherBook.getAuthorName());
book.setPrice(otherBook.getPrice())

ISBN이 기본 유형이 아닌 클래스 인 경우 위의 코드는 컴파일되지 않으므로 나중에 많은 디버깅 시간을 절약 할 수 있습니다.

— 맷 왓슨
소스

1

세터와 게터? 1992 년입니까?

— Miles Rout