스프링 초반 구조 설계

이번에 프로젝트를 시작하기 전에도 항상 고민 했던 부분이 설계 관련 부분이다.

아마 보통 스프링 부트를 사용하여 개발하는 사람들은 이런 구조를 가지고 있을 것이다.

당연히 나도 이렇게 개발을 하고 있었다.

 

이렇게 개발을 하면 JPA를 사용하기에 Repository -> Service -> Controller로 오게 되는데

이 때 Entity 단위의 Repository에서 Service로 그 Service가 Controller로 오기 때문에 Controller가 이런 용도 혹은 Entity 단위로 구성이 된다.

그렇게 개발된 컨트롤러를 Swagger로 본 것이다.

물론 어차피 백엔드의 나는 내가 만든 것이기에 굳이 상관은 없다....

 

하지만 이걸 사용하는 프론트는 페이지를 만들기 위해 여러 컨트롤러들을 찾아서 그 중에서 자신이 사용하는 것을 찾아 사용을 해야한다.

이번 프로젝트는 프론트에 참여한 사람들도 친한 친구들이기에 이 부분을 배려해서 설계를 해보려고 한다.

 

사실 해보는 것이지, 그냥 요즘 유행하는 DDD를 살짝 배껴온 것이다.

 

Repository

일단 Repository를 어떻게 배치할 것인가.

이번에도 JPA를 사용하기에 Repository가 Entity 단위로 생성이 된다.

뭔가 QueryDSL을 사용할까? 했지만 이번에는 그냥 JPA와 JPQL만 사용하기로 나와 약속을 했다.

만약 하나의 Entity를 하나의 도메인에서만 사용한다면 고민을 했겠지만, 이번 프로젝트는 어쩔 수 없이 하나의 도메인에서 대부분의 Entity를 참조한다.

그렇기에 Repository는 Global하게 한 쪽으로 빼고 설계했다.

 

Service

아마 Service 부터는 기존과 좀 달라질 것이다.

Service도 뭔가 용도 단위로 나누기 보다, 그냥 도메인 단위로 나누고 각 서비스에 필요한 Repository를 주입하도록 설계해보았다.

어차피 어떻게 설계를 해도 하나의 Service가 많은 Repository를 사용할 것 같았고, 어차피 나도 도메인 설계에 참여 하기에 도메인들이 왜 어떻게 나뉘는 지 알고 있었다.

그렇기에 그냥 도메인 단위로 패키지를 구성을 했고, 그곳에 하나씩 Service를 넣어주었다.

 

Controller

Controller도 도메인 단위로 나눈 패키지에 하나씩 넣어주었다.

이렇게 하니 API들이 도메인 단위로 나뉘게 되었다.

 

패키지 구성을 보자면 이렇게 되어있다.

이렇게 구성을 하니 

이렇게 API들이 도메인 단위로 분리가 된다.

 

이번 설계는 그냥 짝퉁 DDD이다.

여름이 좀 지나 시간이 남으면 다음 프로젝트 전까지 DDD를 공부하고 들어갈 수 있도록 해야겠다.

물론.. 설계에 정답은 없다! 본인이 편하고 맞다고 생각하는 대로 가면 된다.