jiwhunkim

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

변경감지

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

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

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

jiwhunkim

Posts