자바에서 DDD는 일반적으로 도메인의 모든 가능한 프리미티브를 값 객체로 바꾸는 것을 의미합니까? 필자는 오늘날 collegues와 Stringly (강하게 반대) 형식의 코드에 관해서 동료들과 토론을했습니다. 저는 모든 것을 가치 개체 (물론 개체가 아닌 것은 무엇이든)로 바꾸는 것을 아주 좋아합니다. 그러나 지나친 감정은 구조체 (주소, 거리, 집 번호 등)의 경우에만이를 수행했습니다. , 등) 또는 내장 유효성 검사가 관련성이있는 경우 (예 : 전화 번호). 예를 들어 애완 동물의 이름을 별도의 래퍼 클래스에 넣는 것 (과연 Lombok과 같은 프레임 워크조차도)은 과장 될 것인가, 아니면 첫눈에 쉽게 발견 할 수없는 큰 이점을 제공 할 것인가?Java의 도메인 기반 디자인 - 모든 프리미티브를 값 객체로 변환 하시겠습니까?
규칙은 아니지만 코드에는 비즈니스 언어가 최대한 반영되어야합니다. 원시적 가치를 이해할 수있는 비즈니스 명사로 변경하는 것이 좋습니다. 값 개체가 극히 단순한 경우에도 (단 하나의 value 속성으로) 명시 적으로 이름을 지정할 때 해당 개체를 추론하는 것이 훨씬 쉽습니다. 게다가, 당신의 객체는 당신의 모델/도메인의 지식 위기 동안 바뀔 수 있습니다. 언젠가는 단일 값 객체가 복잡한 구조로 변할 가능성이 매우 높습니다. 값 객체를 처음부터 의미있는 클래스로 설계 할 때 리팩터링이 훨씬 쉽습니다. 또한 정적 유형 유효성 검사의 이점을 얻을 수 있습니다. 거리 이름으로 애완 동물 이름을 설정할 수 없습니다 (단순한 문자열로만 모델링 한 경우 가능합니다).
첫 눈에 쉽게 발견 할 수없는 큰 이점이 있습니까?
큰 장점 중 하나는 비즈니스 논리를 메모리의 데이터 표현과 분리한다는 것입니다. 예를 들어, 돈을 정수, 길거나 고정 소수점 또는 부동 소수점으로 나타내는 경우 인보이스 발행 논리는 실제로 신경 쓰지 않습니다. 구매 가격에 세율 적용과 같은 것에 관심이 있습니다.
그래서 가치 유형은 단순한 "태그"이상입니다. 단위 및 반올림 규칙과 같은 것들을 넣을 수있는 편리한 장소이며 사전 세금 및 세금과 같은 중요한 구분을 추적합니다.
또한 다른 개념을 알아내어 명시 적으로 설명하는 데 도움이 될 수 있습니다. Address은 배송 라벨에 기재되어 있습니까? 지도상의 위치? 부동산 표제? 세금 관할권의 일부입니까? 법적 관할권의 일부입니까?
강력한 유형 안전성과 결합하여 코딩 오류로 인해 비즈니스 오류가 발생하지 않았는지 몇 가지 추가 검사가 이루어집니다 (예 : 전후 세금 합계 합계).
참조 http://stackoverflow.com/questions/43162937/ddd-value-objects-to-cover-every-property –