도메인 모델 기반 패키지 구조

주말 간 우연치 않게 다음 글을 읽었다.

레거시 코드를 점진적으로 개선한 경험

나 또한 계속되는 if문과 중복되는 코드의 압박으로 이런저러한 방법을 찾다 결국은 도메인 모델링까지 도달하게 되었다.(아직 1도 모르지만)

mybatis를 사용한 legacy 프로젝트를 도메인 모델과 유사하게 리펙토링하였는데 신기하게도 이 글의 내용과 비슷한 절차를 따랐다.
-Model, vo, dto를 재정의하고 패키지별로 분리
-typeHandler와 resultMap을 사용하여 쿼리 사용을 최소화하기
같은 것들..

(AOP를 사용한 로깅이나 Exception 전략 등은 나중에 시간을 내서 배워야 할 부분)

'도메인 기반 패키지 구조' 라는 부분이 눈에 띄었다.

요즘 JPA를 사용한 rest api 프로젝트에서는 legacy프로젝트를 리펙토링했던 '도메인 기반 패키지 구조'를 간과했다.
(이동욱님의 책을 들여다보니 역시 도메인 기반 패키지였다.)

하여, 나도 간단히 패키지 변경

완벽하진 않지만.. 나름 깨달은 점은

정리하고 보니 애거리거트 단위가 좀 더 명확하게 보였다.

https://ppiyo5.tistory.com/21

이전에 애그리거트가 어떤 개념인지 찾다가 위 글이 가장 이해가 쉽게 되어 마킹해놨었다.
많은 글에서 애그리거트가 단위로 리포지터리를 작성한다라고 이야기하여 '마스터 테이블이 다 컨트롤 하는 것인가' 라는 생각을 하였는데 이 생각대로 구현하면 모든 연관 관계의 객체들이 마스터 테이블을 통해 CRUD가 되는 모호함이 발생한다.

해당 글에서

• 대부분의 애그리거트는 한개의 엔티티 객체를 가지며, 두 개 이상의 앤티티로 구성되는 애그리거트는 드물게 존재한다.
• 각 애그리거트는 자기 자신을 관리할뿐 다른 애그리거트는 관리하지 않는다.

부분이 이해에 도움을 주었다..