스프링 부트 프로젝트 구조
스프링 부트 프로젝트 구조에 대해 고민하다 보니
Entity, DTO, Repository, Service, Controller 에 대해 알아보게 되고
이를 알아보다 보니 JPA를 알아보게 되고
이를 알아보다 보니 Java 자체에 대해 알아보게 되고
무한 루프에 빠진 기분이다. 리팩토링을 한다는 것 자체가 이미 돌아가고는 있지만 최적의 코드가 아닌 것들에 대해 왜 그것이 최적이 아닌지, 어떤 점이 문제이고 어떻게 개선시켜야 하는지에 대해 고민하다보니 공부할 게 기하급수적으로 늘어난다.
삽질을 하던 와중, 개발자 친구의 조언으로 근본으로 돌아가라는 명을 받았다.
그래서 오늘은 JPA에 대해 좀 알아보는 시간을 가질 것이다.
그래서 JPA가 뭔데
Java Persistence API 라고 한다.
그럼 Persistence(영속성)은 뭐고 API는 정확히 어떤 건데.
영속성이란 말 그대로 영원한 걸 말한다. 객체 생성 작업을 마치고 나서 그 객체가 소멸되는 것이 아니라 영구히 남아있는 것을 말한다.
새롭게 생성한 객체를 바로 소멸시키는 것이 아니라 그 객체를 하나의 데이터로서 저장하고 그 데이터를 다시 활용하는 등의 작업을 하기 위해서는 영속성이 보장되어야 하는 것이다.
API란 단어는 내가 정~말 오랫동안 사전적 의미는 알고 있었지만 정확히 뭔 의미인지는 전혀 체감하지 못했던 개념이다.
쉽게 말하면 프로그램과 프로그램간의 창구 역할인 것이다.
내가 객체의 영속성을 충족시키기 위한 기능을 직접 구현할 것이 아니라면, 이미 누군가가 제공하고 있는 기능을 가져다 쓰는 것이다. 이 가져다 쓰는 것을 가능하게 해주는 창구 역할의 매개체가 바로 API인 것이다
Domain, DTO, Service, Controller
자 그럼 오늘의 주제인 프로젝트 구조로 다시 돌아와보자.
- 가장 먼저는 모든 것의 기본이 될 Entity를 먼저 작성했다. 이미 나의 DB에 저장해둔 형태를 그대로 따와 Entity를 작성했다.
여기서 또 하나 궁금했던 게 있다.
Domain 안에 Entity와 Repository를 집어넣어 두는 것은 왜 그렇게 하는 거지?
Domain의 정의에 대해 살펴보게 됐다. 우리가 다룰, 우리의 관심사 영역을 통틀어 Domain이라고 한다. 그렇다면 우리의 관심사는 당연히 DB의 데이터들을 표현할 몸체인 Entity와 그 Entity에 접근하는 인터페이스인 Repository는 한 몸일 수밖에 없는 것이다!
아직 다룰 내용이 너무 많지만 이 글을 올리지 못하고 계속 임시글에서 내용이 추가되고 있는 탓에 그냥... 또다른 글로 이어가야겠다
