스프링에서 추상화를 어디까지, 어떻게 해야하는지에 대해 학습한다.

강의 내 사이트 링크

강의와 관련된 추천 링크

보강설명

클린 아키텍처

아키텍처에 대해 조금 관심 있으신 분들이라면 레이어 아키텍처에서 지금 제시드린 코드가 클린 아키텍처 쪽으로 점점 변화해가고 있는 것을 확인하실 수 있을 겁니다.

서비스는 추상화하지 않아도 되는게 맞나요?

혹시 이런 생각하셨나요? “서비스가 한번 생성돼서 영원히 같은 일을 해야 하는 것과 별개로, 요구사항에 따른 역할 분리를 위해 추상화 되는 것이 낫지 않나?”라는 생각이 드시나요? 그리고 “그러는 편이 컨트롤러를 테스트하기 편해지는 방향으로 가는 게 낫지 않겠느냐”라는 생각이 드셨다면?

너무 좋은 의견입니다. 사고가 점점 헥사고날 아키텍처를 향해 나아가고 계시네요!

어떤 책에서는 아래처럼 코드를 구성하던데요

interface PostRepository implements JpaRepository<PostEntity, Long> {
}

@Repository
class PostRepositoryImpl implements PostRepository {
// ...
}

네, 다수의 회사에서 이야기하신 방식에 따라 개발하고 있는 것으로 저도 알고 있습니다. 그리고 그렇게 하는 것이 마음에 드셨다면 그렇게 하셔도 됩니다. 사실 JpaRepository를 구현한다해도 이 부분은 얼마든지 fake로 대체할 수 있거든요. 이 또한 선택사항입니다. 다만 강의에서 추구하는 바가 Jpa조차 완전히 분리되어 도메인이 순수 자바로 구성되어있기를 원하기 때문입니다. 이는 클린 아키텍처의 방법론 중 하나인 헥사고날 아키텍처에서 포트 어댑터 패턴과 맥을 같이합니다. 참고하실만한 자료 같이 올려드립니다 : ) 참고 링크