변경감지

JPA 의 기능 대부분을 사용 안한다고 생각하시면 될 것 같습니다. 대신에 DB 에서 REDIS 로 변경하거나 또 다른 JPA 가 아닌 다른 기능을 사용한다고 할 때 코드 변경하는 양이 줄어들겁니다. interface 를 상속 받는 변경된 구현체만 만들면 되니까요.

Service, Repository를 interface로 만들었을때 궁금한게 있습니다.

프로덕트 규모가 작은 프로젝트라고 한다면 오버엔지니어링이 맞습니다. 다만 프로덕트 규모가 커지게 되고 모듈 단위가 다양하다면 모듈 단위로 테스트 가능하게 코드가 만들어져 있지 않으면 사람이 테스트를 수행하는 수 밖에 없습니다. 개발 문서 또는 readme 에 아키텍처 구조, 컨벤션 같은 것을 작성하고 공유하는게 좋습니다.

헥사고날 아키텍처에서 Entity 내의 from과 to 메서드도 분리하고 싶다면?

1. mapper 의존성을 추가해서 해당 변환을 대신 해주거나 직접 구현하는 경우가 있습니다. 다만 domain 과 entity 필드가 대부분 일치한다면 entity 에 method 로 작성해서 코드를 줄이는게 더 좋을수도 있습니다. mapper 의 패키지 위치를 고민해보면 domain 을 다른 무언가로 변환하는 개념으로 infrastructure 에 위치하는게 개념적으로 더 좋은 모양입니다. 그 이유는 domain 하위패키지에 존재한다면 해당 entity 를 domain 이 알아야 한다는 의미이기 때문입니다.