도메인 사이 의존성 줄이기

요새 '오브젝트'라는 책을 다시 보고 있는데, 응집도와 결합도에 관한 내용이 나온다. 대강 LOW COUPLING(낮은 결합도)와 HIGH COHESION(높은 응집도)를 고려해 가며 설계를 하면 변경에 유연한 설계를 할 수 있다는 내용 이었다.

글로는 잘 이해 했다 생각했지만 실제로 어떻게 적용해볼까 고민이 있었는데, 마침 적절한 경험을 한 것 같아서 기록해두려 한다.

예시

상담신청이라는 도메인이 있고, 이번에 타임세일이라는 도메인을 추가하게 되었다.
유저는 상담신청을 할 수 있고, 타임세일을 통해 은 특정 시간에 싼 가격으로 상담신청을 할 수도 있다.

@Entity
public class Consultation {
    @Id
    Long id;

    ...

    @ManyToOne
    @JoinColumn(name = "time_sale_id")
    private TimeSale timeSale;

}

@Entity
public class TimeSale {
    @Id
    Long id;

    ...

}

Consultation은 예전 부터 쭉 존재해 왔던 도메인 영역이다. 반면 TimeSale새로 추가된 도메인 이고, 유저의 반응에 따라서 없어질 수도 있다. 여기서 고민은 시작 되었다.

결합도와 응집도 관점에서 한번 살펴보자

결합도

여기서 위에서 @ManyToOne으로 연관관계를 맺어놓으면 Consultation 도메인과 TimeSale 도메인이 결합을 하게 된다. 서로 다른 도메인이 결합을 하고있다는 것은 그지 좋아보이지 않는다.

응집도

TimeSale은 없어질 수도 있는 도메인다. 그리고 개발 초창기 였기 때문에 유저의 반응에 따라 이리 저리 변하기 쉬운 도메인이다. 위 코드 처럼 직접 연관을 갖게 되면 TimeSale의 변경이 Consultation에도 전파될 위험이 생긴다.

그리고 Consultation과 TimeSale은 서로 다른 생애주기를 가지고 있기 때문에 더더욱 연관관계를 가지는 것은 좋지 않아 보인다.

어떻게 해결할까?

두 도메인 간 연관관계를 줄여야 하는데 어쨌든 Consultation은 TimeSale을 알고 있어야 한다. 이런 고민을 다른 동료들에게도 공유를 했고, 책을 통해 공부한 내용과 종합해서 결론을 내렸다.

해결 방법은 Consultation 안에 Consultation의 TimeSale 도메인 모델을 만드는 것 이었다.

@Entity
public class Consultation {
    @Id
    Long id;

    ...

    @Json
    private ConsultationTimeSale consultationTimeSale;

}

이런식으로 Consultation과 TimeSale 사이의 연관관계를 끊었지만 Consultation에서 필요한 TimeSale의 정보는 ConsultationTimeSale에서 가지고 있을 수 있다. TimeSale의 변경에 대한 영향을 줄일 수 있는 것이다.