- 모듈 구조를 세분화하는 것에 있어서 정해진 규칙은 없다. 최범균님 개인적으로는 한 패키지에 가능하면 10 ~ 25개의 타입 개수를 유지하도록 하려고한다. 이를 넘어서면 패키지를 분리한다. (도메인주도설계시작하기 - 최범균)
- 애그리거트
- 도메인들을 상위 수준에서 조망할 수 있게 하는 개념.
- 도메인 규칙에 따라 함께 생성되는 구성요소는 하나의 애그리거트에 묶일 가능성이 크다.
- A가 B를 갖는다고 하면 A와 B 구성요소가 같은 애그리거트에 속한다고 생각하기 쉽지만, 각각의 변경이 서로에 영향을 주지 않는다면 같은 애그리거트에 속한다고 보기 어렵다.
- 최범균님의 경험 상 애그리거트가 한 개의 엔티티 객체만 갖는 경우가 많으며 두개 이상의 엔티티로 구성되는 경우는 드물었다고 한다.
- 애그리거트 루트는 애그리거트에 속한 도메인들의 일관성을 유지시켜주는 대표 도메인이다.
- 애그리거트 외부에서 애그리거트에 속한 객체를 직접 변경하면 안되며 루트 도메인을 거쳐 변경해야한다.
- 애그리거트 루트를 통해서만 도메인 로직을 구현하게 만드려면
- set메소드 공개범위로 x
- 밸류 타입은 불변으로 를 습관적으로 적용해야한다.
- DB 트랜잭션 범위는 작으면 작을 수록 성능상의 이점을 가져간다. 따라서 하나의 트랜잭션에서 하나의 애그리거트만 수정하도록 하는 것이 좋다. (성능 상의 이점을 가져가는 이유는 한번에 처리하는 테이블 수가 줄어듦으로서 잠금하는 대상이 줄어들고 동시에 처리할 수 있는 트랜잭션이 많아진다는 의미기이 때문.)
- 레포지토리도 하나의 애그리거트당 하나만 만든다! (order와 orderLine 은 db에 테이블은 다로 있지만 레포지토리 객체는 하나만 만든다.)
- ID를 이용한 애그리거트 참조
- 객체간에 db 테이블간의 연관관계를 가진 것처럼 ORM을 사용할 경우 onetomany등의 어노테이션으로 객체간에 참조를 가능하도록 할 수 있지만, 이는 자칫하면 다른 애그리거트와의 결합도를 높일 수 있게된다. 이외에더 몇가지 문제가 더 있을 수 있으며 이를 완화하기위해 ID로 참조하도록 한다. 쉽게 코드로 생각하면 객체를 멤버변수로 지정하고 oneTomany등의 어노테이션을 사용하는 것이 아닌 참조하려는 객체의 id값을 멤버변수로 가진다. (다른 애그리거트 사이에는)
- 객체 참조 방식을 사용하는 대신 ID 참조 방식을 사용하면 조회 시 성능이슈가 발생할 수 있는데, ID로 참조된 객체까지 조회하려면 N개의 도메인을 조회했을 때 ID로 매핑된 N 개의 객체도 한번 더 조회해야하는 n+1이슈가 발생한다. 이는 지연로딩에서도 발생하며, 객체 참조 방식(즉시로딩으로)을 사용하지 않고 해당 이슈를 해결하려면 조회 용 별도의 DAO를 생성해 사용하면 된다.
2024.04.05의 깨달음
· 5 min read