클린 아키텍처에 대한 지난 프로젝트 회고

https://techblog.woowahan.com/2647/

주니어 개발자의 클린 아키텍처 맛보기 | 우아한형제들 기술블로그

해당 글을 읽고 나니 내 개인 프로젝트에서 클린 아키텍처로 어떻게 적용할 수 있을지 고민해 보았다.

 

용도별 DTO 분리

컨트롤러에서 서비스, 서비스에서 DAO까지 데이터를 전달할 때 뷰에서 받은 객체를 넘기는 것은 좋지 않다.

레이어 간 의존성이 강하게 생기므로 단순하고 고립된 형태의 DTO로 넘기는 것이 좋다고 한다.

 

클라이언트에서 받은 데이터의 종류는 여러 가지가 있다. 대표적으로 나누면 등록, 수정, 삭제가 있는데, 나는 이에 대해서 한 가지의 DTO로 처리를 했다. 등록, 수정에 관해 DTO 내의 데이터는 프로젝트를 진행하면서 달랐던 적이 한 번도 없었기 때문이다.

 

그러나 다음 프로젝트부터는 사용되는 데이터가 같더라도 DTO를 나눌 필요가 있다고 생각했다.

왜냐하면 등록 수정에 대해 쓰이는 필드는 같더라도 비즈니스 로직에서 유효성 검사의 유무나 값을 다룰 때 각자 다른 방법으로 다룰 수 있기 때문이다.

내 프로젝트의 경우 규모가 작아서 로직상 쓰이는 방법이 다르지 않아서 체감되지 않았지만, 만약 위처럼 생성일에 대해 유효성 검사가 필요하거나, 결국 프로젝트가 진행되면서 확장이 될 경우 어떤 식으로 수정, 등록 방법이 바뀔지 모르기 때문이다.

 

DTO - Entity 간 의존성 줄이기

Entity에서 DTO, DTO에서 Entity로 변환하고자 할 때 팩토리 메서드를 어느 한쪽 클래스에 선언해 둘 필요가 있었다.

사실 어느 쪽에 생성해서 이용하더라도 상관이 없을 것이라고 생각해서 보통은 Entity에 선언해 두곤 했는데, 의존성 규칙에 위반할 수 있다는 것을 이번에 직접적으로 알 수 있었다.

 

Entity에서 DTO를 바라보게 되면 결국 DTO를 변경할 경우 Entity에서 필히 코드의 변경이 이루어져야 하기 때문이다.

반대의 경우도 마찬가지이다.

그래서 나는 이번에 변환하는 과정을 제3의 클래스에서 할 수 있도록 Mapstruct를 사용했다.

그래서 로직에서 Mapper 클래스를 이용해서 변환을 하기 때문에 DTO - Entity 간의 의존성을 낮출 수 있었다.

(사실 DTO, Entity 둘 중 하나라도 변경되면 Mapper를 수정해야 하기에 의존성이 새로 생기지만, Entity에 대해 변경 가능성을 낮출 수 있었기 때문에 어쩔 수 없었다고 생각했다.)

 

작성 중