도메인 모델에서 set 메서드는 문제가 될 수 있다.
사용자 정보를 담는 User 클래스를 작성할 때 데이터 필드에 대한 get/set 메서드를 작성할 수 있다.
문제를 막으려면?
DTO의 get/set 메서드
DTO는 프레젠테이션 계층과 도메인 계층이 데이터를 서로 주고받을 때 사용하는 일종의 구조체이다.
오래된 프레임워크에서는 요청 파라미터나 DB 칼럼의 값을 설정할 때 set 메서드를 필요로 했기 때문에 구현 기술을 적용하려면 어쩔 수 없이 DTO에 get/set 메서드를 구현해야 했다.
-> DTO가 도메인 로직을 담고 있지는 않기 때문에 get/set 메서드를 제공해도 도메인 객체에 데이터 일관성에 영향을 줄 가능성이 높지 않다.
요즘 개발 프레임워크나 개발 도구는 set 메서드가 아닌 private 필드에 직접 값을 할당할 수 있는 기능을 제공한다.(set 메서드가 없어도 프레임워크로 데이터 전달 가능)
그렇기에 프레임워크가 필드에 직접 값을 할당할 수 있다면 set 메서드 대신 해당 기능을 최대한 활용하는게 좋다.
-> 이렇게 하면 DTO도 불변 객체가 된다. (불변의 장점을 DTO까지 확장할 수 있게 됨)
도메인 용어
도메인 용어를 a, b, c 가 아닌 payment_wating, preparing, shipped와 같이 도메인에서 사용하는 용어를 최대한 코드에 반영한다면 이해하기 편할 것이다.
이는 코드를 용어로 인해 더 빠르게 이해하고 해석할 수 있게 해준다.(가독성도 높여줌)
또한 도메인 용어로 도메인 규칙을 코드로 작성하게 되므로 의미를 변환하는 과정에서 발생하는 버그도 줄일 수 있다.
생각보다 도메인 주도 설계에서는 언어를 중요시하게 여기고 프로젝트에 전문가, 관계자, 개발자가 도메인과 관련된 공통의 언어를 만들고 이를 대화, 문서, 도메인 모델, 코드 등 모든 곳에서 같은 용어를 사용한다.
-> 이렇게 함으로써 소통 과정에서 발생하는 용어의 모호함을 줄일 수 있고 개발자는 도메인과 코드 사이에서 불필요한 해석 과정을 줄일 수 있는 장점이 있다.
그렇기 때문에 도메인 용어에 알맞는 단어를 찾는 시간을 아까워하지 말자!
| 요소 | 설명 |
|---|---|
| 엔티티 (ENTITY) | 고유의 식별자를 갖는 객체로 자신의 라이프 사이클을 갖는다. 주문(Order), 회원(Member), 상품(Product)과 같이 도메인의 고유한 개념을 표현한다. 도메인 모델의 데이터를 포함하며 해당 데이터와 관련된 기능을 함께 제공한다. |
| 밸류 (VALUE) | 고유의 식별자를 갖지 않는 객체로 주로 개념적으로 하나인 값을 표현할 때 사용된다. 배송지 주소를 표현하기 위한 주소(Address)나 구매 금액을 위한 금액(Money)와 같은 타입이 밸류 타입이다. 엔티티의 속성으로 사용할 뿐만 아니라 다른 밸류 타입의 속성으로도 사용할 수 있다. |
| 애그리거트 (AGGREGATE) | 애그리거트는 연관된 엔티티와 밸류 객체를 개념적으로 하나로 묶은 것이다. 예를 들어 주문과 관련된 Order 엔티티, OrderLine 밸류, Orderer 밸류 객체를 ‘주문’ 애그리거트로 묶을 수 있다. |
| 리포지터리 (REPOSITORY) | 도메인 모델의 영속성을 처리한다. 예를 들어 DBMS 테이블에서 엔티티 객체를 로딩하거나 저장하는 기능을 제공한다. |
| 도메인 서비스 (DOMAIN SERVICE) | 특정 엔티티에 속하지 않은 도메인 로직을 제공한다. ‘할인 금액 계산’은 상품, 쿠폰, 회원 등급, 구매 금액 등 다양한 조건을 이용해서 구현하게 되는데, 이렇게 도메인 로직이 여러 엔티티와 밸류를 필요로 하면 도메인 서비스에서 로직을 구현한다. |
참고자료
- 도메인 주도 개발 시작하기: DDD 핵심 개념 정리부터 구현까지
https://product.kyobobook.co.kr/detail/S000001810495