학습 자료
- https://spring.io/projects/spring-data-jdbc#overview
- https://martinfowler.com/bliki/DDD_Aggregate.html
- https://eocoding.tistory.com/36
학습 계기
- Spring Data Jdbc를 활용해서 미션을 진행하고있다.
- 이전에는 단순히 자주 사용되는 쿼리에 대해서 매핑해주는 편리한 기능으로만 생각했었다.
- Test코드를 작성하면서 @JdbcTest와 @DataJdbcTest 어노테이션의 차이에 대해서도 모르고 있었다.
- @JdbcTest는 DataSource만을 활용하는 테스트
- @DataJdbcTest는 Spring Data Jdbc repository를 활용하는 테스트
- 큰 차이를 인식하지 못하고 사용법을 익히고, 활용하고 있었다.
- 이 후 그룹리뷰와 마스터 회고시간에 DDD와 Aggregate라는 키워드를 듣고 키워드에 대해서 검색하게 되었다.
Spring Data Jdbc
- Spring Data JDBC aims at being conceptually easy.
- 쉽게 사용할 수 있도록 하는 것이 이 기술의 핵심인 것 같다. 아직 나는 Jpa에 대해서 공부를 하지 않아서 잘 모르겠지만, caching, lazy loading, 등 몇가지의 Jpa의 기능을 지원하지 않는다고 한다.
- Jpa의 이러한 기능들이 사용자가 기능을 제대로 이해하지 못하고 사용할 때 부수효과가 많이 나타나고, 익히기에도 쉽지 않은 것 같다.
DDD_Aggregate
DDD의 개념은 다시 정확하게 이해하고 정리하도록 하자.
내 말로 쉽게 풀어적고 싶었으나, 쉽지 않아서 단순하게 번역한 내용이 많다. 참고자료를 보시는 것을 추천!
- Spring 공식문서에 따르면 Spring data repository들은 Domain Driven Design의 repository에서 영감을 받아서 만들어졌다고 되어있다.
- DDD의 repository의 컨셉 중 하나가 Aggregate Root 당 하나의 repository를 가지는 것이다.
- DDD에서의 Aggregate는 하나의 단위로 처리되어야 할 도메인 객체의 집합체이다.
- 마틴 파울러는 예시에 따르면
주문(order)과 그세부 항목(line item)은 개별적인 객체이지만 하나로 관리 되어야 하는aggregate라고 한다. - 그리고 aggregate에는 반드시 aggregate root를 필요로 한다.
- 예시 속에서 aggregate root는
주문이 된다. - aggregate는 데이터 저장소의 기본적인 요소가 되고, 한번에 저장되어야한다.
- 각 객체가 따로따로 저장된다면, 데이터 무결성이 깨지는 경우가 발생한다.
- transaction은 aggregate 경계를 넘어갈 수 없다.
- DDD의 aggregate는 종종 컬렉션으로 착각하게 되지만, 도메인 컨셉(order, clinic visit, playlist)! 컬렉션도 가질 수 있고, 필드도 가질 수 있다.
- 다른 맥락에서도(예시로 UML) aggregate라는 개념이 있지만, DDD aggregate와는 다른 개념!
aggregate는 데이터 저장소의 기본적인 요소가 되고, 한번에 저장되어야한다.
- 이 문장이 Spring Data Jdbc를 활용할 때 가장 중요한 핵심인 것 같다.
- 그래서 구현할 때, 도메인 객체에 대해서 aggregate가 되는 것을 고려하고, aggregate root에만 repository를 할당해야 한다.
- 무조건 이 원칙을 따라야하는 것은 아니겠지만, 참고하면 좋은 설계와 구현이 되지 않을까....?
- Aggregate root가 아닌 객체에 대해서는 READ 기능만을 열어두고, C,U,D 기능들은 사용못하도록하여 구현 하면 되지 않을까?? 다음 PR에 리뷰어에게 질문남겨 봐야겠다.
차곡차곡