- 실무에서 프로젝트 구현시 보통 폴더 구조를 어떤식으로 하시나요?
-> 뭔가 약팔이 처럼 실무에서는 이렇게 하는게 정석입니다. 라고 말씀드리면 좋겠지만... 솔직하게 말씀드려서 저는 지금도 프로젝트를 진행할 때 마다 패키지 구조를 고민합니다. 왜냐하면 이 부분은 딱 정해진 정답이 있다기 보다는. 현재 프로젝트의 상황과 규모에 따라서, 거기에 맞는 유지보수하고 확장하기 쉬운 구조가 있기 때문입니다.
예를들어서 블로그 프로젝트가 정말 너무 작아서 단순하게 API 하나를 처리하면 끝난다고 하면, 그냥 패키지 하나에 다 몰아 넣고, 최대한 단순하게 처리하는 것이 좋다 생각합니다.
project
그런데 프로젝트에 요구사항이 추가되면서 기능이 증가하면 이제 컨트롤러, dto, entity, 비즈니스로직을 처리하는 serivce 등으로 패키지를 분할하는게 의미를 가지겠지요.
project
-
controller
-
dto
-
entity
-
serivce
여기서 프로젝트가 정말 더 커져서 여러 도메인이 추가되면 도메인 단위로 상위 패키지 개념을 더 추가할 수 있습니다.
예를 들어서 단순히 블로그 API 만 제공하다가, 회원 기능이 추가되면 다음과 같이 될 수 있겠지요.
project
-
blog
-
controller
-
dto
-
entity
-
service
-
-
member
-
controller
-
dto
-
entity
-
service
-
그런데 이렇게 구성해보니까, 블로그 컨트롤러에서 회원과 관련된 서비스를 자주 사용합니다. 엔티티들도 서로 연관관계가 생깁니다. 그래서 다음과 같은 구조로 변경합니다.
project
-
controller
-
blog
-
member
-
-
service
-
blog
-
member
-
-
entity
-
blog
-
member
-
여기서 더 나아가면 패키지 구조를 넘어서 멀티모듈 프로젝트로 가면서 프로젝트 자체를 여러개로 구성할 수도 있습니다.
제가 이 과정을 통해서 말씀드리고 싶은 진짜 핵심은!
프로젝트가 성장함에 따라 프로젝트 구조도 현재 상황에 맞추어 성장하고 변경할 수 있어야 합니다.
결국 이 부분은 진지한 고민과 학습 그리고 다양한 경험을 통해서 길러질 수 있는 아키텍트의 중요한 기본기라 생각합니다.
단순한 질문을 제가 좀 길게 답변을 드린 것 같네요 ㅎㅎ 다시 질문으로 돌아오면^^;;
질문: 강의와 같이 api 패키지를 하나 만들고 Controller 클래스 안에 static 클래스로 dto를 만드시나요? 아니면 api 패키지 안에서 다시 패키지들로 나누시나요?
-> 이 부분은 해당 컨트롤러만 사용하는 DTO면 그 안에 만들고, 여러 클래스가 공유해야 하면 외부에 별도로 생성합니다. 패키지는 프로젝트가 복잡해지면 추가하고, 프로젝트가 단순하면 별도의 패키지를 만들지 않고 같이 둡니다.
