도메인
도메인은 구현해야할 소프트웨어의 대상이다.
쇼핑몰을 생각해보면 쇼핑몰은 대상, 그리고 상품조회, 주문, 배송, 결제 등등이
하위 도메인이 된다.
그리고 도메인이라고 해서 고정된 하위 도메인이 존재하는건 아니다.
결제같은것을 PG사에 위임하니까 말이다.
도메인 모델 패턴
기존의 나는 흔히 말하는 MVC 레이어 아키텍처를 사용했다.
단순히 Controller, Service, Repository세개를 사용해서 구현했었다.
이것은 내가 넥스트스텝에서 TDD와 클린 코드를 수강했어도 변하지 못했다.
근데 이 방식이 아니라 DDD책을 보면서 주워들었던 도메인 모델 패턴을 봤다.
그래도 말만 바뀌었지 느낌은 전과 같았다.
의존은 화살표 방향으로 주입이 된다.
Presentation- 사용자의 요청을 처리하고 사용자에게 정보를 보여준다.
- 사용자는 사람이 아니라 외부 시스템일 수 있다.
Application- 사용자가 요청한 기능을 실행
- 비즈니스 로직을 구현하지는 않고 도메인의 계층을 조합해주기만 함
Domain- 이 설계의 가장 핵심
- 시스템이 제공하는 도메인들의 규칙을 구현
InfraStructure- DB나 메시징 시스템 같은 외부 시스템의 연동을 처리함
핵심 규칙들은 도메인 모델에만 위치하기 때문에 규칙이 바뀌거나 확장해야 된다면
다른 코드에 영향을 끼치지않고 모델들에 반영해주어야 한다.
도출한 모델들은 엔티티와 값 타입으로 구분할 수 있다.
엔티티와 값타입을 제대로 구분하여야 도메인을 잘 설계하고 구현할 수 있다. 👍
엔티티
엔티티는 식별자를 가진다. 이 식별자는 엔티티 객체마다 고유해야 한다.
그래서 회원의 경우 회원번호가 서로 다르다.
이것이 바로 식별자가 되는것!!
다른 값이 바뀌어도 이 엔티티 객체가 생성되거나 삭제되기 전까지 유지된다.
그렇기 때문에 이 식별자 값이 같다면? 같은 객체❗️
그렇다면 이 식별자 값으로 equals(), hashCode()를 재정의 할 수 있다.
식별자 생성
그러면 식별자를 생성해야 하는데
엔티티의 식별자를 생성하는 시점은 도메인의 특징과 사용하는 기술에 따라 달라진다.
- 특정 규칙에 따라 생성
- UUID같은 고유 식별자 사용
- 값 직접 입력 (개인적으로 제일 안좋다 생각)
- 일련번호 사용 (시퀀스나 DB의 auto-increment)
모델
배송지의 집주소가 우편번호 + 도로명주소 + 상세주소 이렇게 같이 사용하는게 대부분인데,
세 가지 데이터는 다르지만 개념적으로는 하나로 일맥상통한다. 바로 주소
값 타입은 바로 이럴때 사용하는 것이다.
이 값타입의 장점은 이 값들만의 기능을 추가할 수 있다.
이 값객체의 값을 바꾸는건 기존 데이터를 두기보단 변경이 되면 새로 생성하는
불변 객체 를 생성하는 방식을 선호한다.
불변으로 만드는 이유는 안전한 코드를 작성할 수 있다는 곳에 있다.
setter 메소드로 값을 바꾼다면 다른 로직에서 잘못 반영이 되는 불상사를 초래할 수 있다.
그래서 두 값 객체를 비교할 때에는 모든 인자가 같은지를 체크해주어야 한다.
무지성 Getter/Setter 남용금지
getter는 어쩔수 없는 경우가 있다고 할지라도,
setter는 값이 깨지는것을 막을수는 없다. + 핵심 개념이나 로직을 망가뜨릴수 있다.
