도메인 리팩터링 실천하기

[Kimprodp]

현재 구조에서 고민했던 부분

• 리뷰 서비스 특성 상, 템플릿과 템플릿에 연관된 객체들을 사용할 일이 많은데 매번 repository를 통해 가져와야 한다. 이 때문에 캐싱을 사용하려 하지만, 코드 레벨에서 근본적인 것이 해결 되어야 함
• 현재 패키지 구조의 최상위는 도메인 별로 나뉨 즉, DDD로 따지면 애그리거트 끼리 묶여서 패키지를 이룬다. 근데 다른 패키지의 자원을 사용할 일이 있다면 service에서 다른 패키지의 repository를 통해 마구마구 가져온다.
• 그리고 가져온 도메인을 사용하면서, 객체지향을 위해 '물어보는 메서드'가 구현된다. 즉 getter로 가져와서 사용하지 않고 물어보는 메서드가 많이 생기는데, 이 때문에 현재 패키지와 전혀 상관 없는 메서드들이 생겨나게 된다.
• 쉽게 생각하면 연관관계 끊고, 간접 참조하고, 패키지 분리했지만 필요하니 무분별하게 가져다 쓰는 형태가 된다. 만약, 서비스가 커져서 지금 패키지 형태로 서비스가 분리된다면 어떻게 될까

리팩터링 내용

구조의 변화

• as-is : controller - service - domain - repository
• to-be : controller - facade - domain -repository

현재 구조 상황

• service에서 비즈니스 로직 수행
• domain은 비즈니스 기능 보다는 거의 엔티티의 역할을 함
• 비즈니스 로직이 처리되는 service에서 다른 패키지 의존 (repository)
• dto가 비즈니스 로직까지 내려와서 dto <> domain 매핑을 진행
  

변경해야 할 부분

• 계층별 역할과 책임을 확실히 나눈다.
• 리뷰 서비스에서 제공하는 기능은 domain에서 처리한다. 즉 핵심 기능, 비즈니스 로직은 domain에서 처리한다.
• domain은 비즈니스 로직을 처리하는 과정에서 엔티티를 사용할 수 있다.
• 모든 외부 요청에 대한 처리는 facade에서 처리한다.
• facade는 dto와 domain의 변환을 담당하고, 외부에서 자원을 가져오고, domain 계층으로 전달하는 역할을 한다.
  

다른 패키지의 도메인 사용

• 리뷰를 등록하거나 조회할 때, 템플릿을 한 번 가져오면 템플릿 내부 정보를 다 사용할 수 있어야 하지만, 템플릿 관련 엔티티들이 전부 id로 분리되어 있어서 매번 id를 통해 자원을 가져온다.

• 엔티티의 연관관계를 재설정하는 방법도 있지만, 다른 패키지에서 영속화 대상인 엔티티를 넘기고 사용하는 것은 변경에 취약해지는 구조가 되기 쉽다. (트랜잭션 내에서 엔티티를 변경하게 되면 변경 내용이 반영될 수 있음)

• 따라서, 엔티티에 영향이 없는 도메인 객체를 하나 만들고, 필요한 연관을 갖게 한다.

• '템플릿'의 역할은 주로 다른 패키지에서의 사용이다. 따라서 사용 가능한 도메인을 만든다.
  

• 하지만 이 객체를 다른 패키지에서 직접 사용하게 되면 다른 패키지와의 협력 과정에서 이 객체가 많은 역할을 맡게 될 수 있다.

• 즉, 패키지 간 결합도가 증가하고 경계가 모호해진다.

• 따라서 연관 관계를 한 곳으로 몰아서 캡슐화 할 수 있는 클래스를 만들어서 사용한다.

• 리뷰 등록 시 사용하는 TemplateValidationContext 가 StructuredTemplate를 사용하여 필요한 메서드들을 조합해서 만들어둔다.

• 리뷰 등록 시, 검증 과정에서는 StructuredTemplate을 사용할 필요 없이, TemplateValidationContext 만을 사용해서 검증할 수 있어서,

• 다른 클래스에서는 템플릿 패키지에 대한 의존이 없어지게 된다.
  
  
  
  

• 이 객체의 변환도 facade에서 하기 때문에 domian에 있는 ReviewRegisterService에도 다른 패키지의 의존성이 없다.
  
  

추가 고민 사항

• 다른 패키지의 자원을 가져오는 방식으로 현재는 facade - service 간의 통신을 하고 있지만,
• service는 domain 계층이니, 외부 계층인 facade -facade 간의 통신으로 데이터를 주고받는 것이 더 적합하다 생각한다.