🍡 DDD 적용하기 - 2

DDD 적용하기 - 1 개념을 토대로 구현하려고 한다.

---

1. 매핑 구현

• 엔티티는 @Entity로 매핑
• 한 테이블에 엔티티와 밸류가 같이 있을 경우에 밸류는 @Embeddable, 밸류 타입 프로퍼티는 @Embedded로 매핑

Aggregate 단위로 묶은 그림

지난번에 그린 그림을 가져와 보았다. DDD 적용 이전과 가장 달라진 점은 Question이 Entity에서 Value가 되었다는 것이다.

Form과 Question은 일대다 관계이기 때문에 밸류 컬렉션을 별도 테이블로 매핑하는 방법을 사용한다. @ElementCollection과 @CollectionTable을 통해 구현할 수 있다.

기존 Form 테이블 Question 프로퍼티

    @OneToMany(mappedBy = "form")
    private List<Question> questionList;

밸류 컬렉션 테이블 매핑 후

    @ElementCollection
    @CollectionTable(name = "Question", joinColumns = @JoinColumn(name = "orderId"))
    @OrderColumn(name = "questionId")
    private List<Question> questionList;

이곳에서 조인하고자 하는 테이블 이름을 @CollectionTable의 name으로 지정하고 joinColumns로 외부키로 쓰일 컬럼명을 지정할 수 있다.
또, @OrderColumn을 리스트의 인덱스로 쓰일 이름을 지정할 수 있다.

기존 Question 테이블

@Getter
@Setter
@Entity
@Table(name = "Question")
@NoArgsConstructor
@EqualsAndHashCode(of = "id")
public class Question extends AbstractTimestamp {
		...
}

밸류 컬렉션 테이블 매핑 후

@Embeddable
@EqualsAndHashCode(of = "id")
public class Question extends AbstractTimestamp {
		...
        
        protected Question() {
        }
        
        ...
}

일대일 관계의 Value와 마찬가지로 @Entity 대신 @Embeddable로 매핑 설정한다.
이전과는 달리 Value는 불변해야하므로 Getter, Setter를 제거하고, JPA 적용을 위해 기본 생성자는 protected로 지정하여 다른 곳에서 사용하지 못하도록 보호한다.

---

2. 패키지 구조 리팩토링

전체 구조

이전에는 위와 같은 계층형 패키지 구조를 사용했다. Controller 역할을 하는 클래스는 모두 controller 패키지 하위에 위치했다. 패키지만을 보고 프로젝트의 전체적인 구조 파악은 가능하지만, 패키지마다 너무 많은 클래스를 포함하고 그들끼리의 연관관계 파악 등이 어렵다.

현재 presentation, application, domain, infrastructure 각 계층 안에서 도메인별로 패키지를 나누어 구성했다. 자세히 들여다보면 다음과 같다.

• presentation : Controller로 클라이언트의 요청을 처리한다. Mapper를 활용해 데이터를 알맞게 가공해서 넘겨준다.
• application : Facade라고 명명했으며 해당 요청에 필요한 작업들을 정의하고 호출한다. Domain Service 외의 알림 전송 같은 기타 서비스를 호출해주기도 한다.
• domain : Entity, Domain Service, infrastructure에서 구현 될 인터페이스가 정의되어 있다. 도메인의 상태 변경이나 도메인 값으로 이뤄지는 비즈니스 로직들이 수행된다.
• infrastructure : 가장 low level 구현체로 기술적 기능들을 제공한다. DIP 개념을 활용하여 domain 계층에서 추상화 된 인터페이스를 구현한다.

패키지간 데이터 전달에 있어서 Info, Command, Request, Response 등의 객체로 데이터를 감싸주어 엔티티를 직접 전달하지 않도록 하였다. 패키지 의존 방향이 모두 domain 계층을 바라보고, 도메인 별 응집도가 높아졌다.

예시

아직 응용 서비스 단계까지 코드를 작성하지 않아 다소 조그맣지만 현재까지의 패키지 구조의 일부를 예시로 가져왔다. constant는 Entity에 포함된 ENUM 값들을 모아놓은 패키지다.

변경한 패키지 구조는 아래와 같다.

기존에는 PlanStatus가 어디에 쓰이는건지 바로 파악하기 어려웠다면, User 도메인 안에 자리한 PlanStatus는 유저의 구매 여부를 나타냄을 알아차리기 쉬워졌다. 또 같은 패키지 안에 위치하여 패키지간 import가 현저히 줄어듬을 확인할 수 있었다.

---

그 외에도 설계시 고려할 점은 아래와 같다.

도메인의 특성에 따라 연관관계를 제약할 수 있다.

• 사용되지 않는 방향 제거를 통해 구현이 단순해지고 이해가 쉬워짐
• 나머지 양방향 연관관계도 의미가 뚜렷해짐

애그리거트는 완전해야한다.

• 상태 변경 기능 시나, 표현 영역에서 애그리거트의 상태 정보를 보여줄 때 애그리거트가 완전해야 하므로 컬렉션에 대해 즉시 로딩 설정한다.
• 하지만, 조회의 빈도가 변경의 빈도보다 훨씬 높고 애그리거트에 따라 특정 테이블은 즉시 로딩이 필요 없는 경우도 있다.