[항해 플러스 백엔드 - 3주차] 이커머스 설계

이번 챕터를 시작하며 꼭 해내고 싶었던 목표

 - DDD 기반, 동시성을 고려해 정규화된 ERD 설계하기

- 다양한 케이스를 고려한 시퀀스 다이어그램 만들기

- Swagger를 이용해 빠르게 mockAPI 배포하기

 

이번 챕터를 마무리하며 가장 기억에 남는 성취

- DDD 기반, 동시성을 고려해 정규화된 ERD 설계하기

 

이번 챕터에서 반드시 이뤘으면 했는데 이루지 못한 것(아쉬운 점)

- MockApi를 좀 더 깔끔하게 정리해서 만들지 못한 것?

 

내가 강화해야 할 강점 중 가장 중요하다고 생각하는 한 가지

-  내가 선택한 설계에 이유와 근거를 만들며 장단점을 잘 아는 것

 

내가 개선해야 할 개선점 중 가장 중요하다고 생각하는 한 가지

- 바로 코드부터 짜는 것이 아니라 좋은 설계가 필요하다. 시퀀스 다이어그램, 플로우 차트, 클래스 다이어그램 등등이 있으며 패키지 구조도 나만의 철학이 있어야 한다. 설계의 방향은 DB 관점의 ERD 설계도 중요하며, 동시에 100% 디비 주도 개발이 아닌 도메인 주도 개발로 나아가야 한다. 항상 "적당히" 타협점을 찾는 것이 어려운 일인데 유연성과 경험이 필요하다. 정해진 규칙과 약속들은 일반적인 상황에서 지키면 좋지만 모든 상황에 100% 정확하게 같은 답을 내놓을 수 없다. 명확하게 떨어지는 정답이 정해져 있으면 좋겠다고 생각을해서 그런지 경계에 있는 느낌을 받으면 애매하다.

 

 첫째로 dto 패키지를 어떤 수준에서 어느 곳에 만들어야 하는지 연습이 더 필요하다. xxController, xxService 별로 만들 수도 있고, xxController만 만들거나 xxService에만 만들 수도 있다. 누군가는 xxController 중심으로 dto 생성을 시작하며 누군가는 xxService 중심으로 dto를 생성한다. 꼭 이름은 xxRequest, xxResponse로만 써야하는 것도 아니다. 한가지 공통규약으로 느끼는 것이 있다면, 어떤 dto가 xxController에서만 사용되면 controller 패키지에 해당 dto들이 위치해야되고, 어떤 dto는 xxService에서 사용되면 service(혹은 domain) 패키지에 해당 dto를 생성하는 것이다. 즉, dto가 사용되는 종단 계층에 만든다. 네이밍이 너무 길지 않도록, API 기능마다 신규 dto파일들이 생성되는 것을 어떻게 하면 줄일 수 있을지 고민이다. 

 

 둘째로, 보통 xxService-xxRepository에 비지니스와 DB관련 로직이 다 들어가 있는데 다른 방법도 고민이 필요하다. 조회/쓰기 작업 종류에 따라, 역할(성격)에 따라서 xxRepository를 xxxManager, xxxReader, xxxModifier 등 다양한 방식으로 쪼갤 수 있다. 이들을 component라고 하는데 usecase에서 조립하여 사용한다. 최종적으로 xxController는 여러 개의 usecase에 의존한다. (이런 경우 xxService를 아예 없앨 수도 있다. xxService의 역할을 usecase가 대체한다) 즉, 크게 바뀐 점은 기존에 xxController는 일부 xxFacade를 제외하고 xxService에 의존하는 방법으로 코드를 작성했다면, 유연성을 높이기 위해 xxController는 ModifiyLectureUsecase, GetMyApplicationUsecase 등 비지니스를 독립시켜 usecase에 의존한다. 클래스명도 직관적이어서 어떤 역할을 하는 클래스인지 파악이 빠르고 기존의 xxService가 너무 비대해지는 것을 예방할 수 있다. 사실상 용어 차이로 봐도 무방하며 ModifiyLectureUseCase -> ModifiyLectureService, GetMyApplicationUsecase -> GetMyAppliactionService도 가능하다. 또한 usecase는 결국 단일 service/facade로 이해할 수도 있다.

 

 셋째로, 도메인과 엔티티의 분리이다. JPA을 위한 영속성 관련 어노테이션들을 설정하는 것이 JPA 도메인을 그대로 엔티티로 사용하는 것이라는 사실을 최근에 알았다.(초심자가 학습하기에는 가장 정석적인 방법이라고 생각한다.) 이런 방식의 장점은 JPA의 기능을 극대화할 수 있으나, 전반적인 테이블 구조의 이해와 N+1 문제, 영속성 전이, fetch join 등 다양한 지식이 필요하므로 러닝커브가 높다. 따라서 영속성이 관리되며 DB와 밀접한 관계를 지니는 엔티티와 DB와 상관없이 비지니스 로직에만 집중할 수 있도록 도메인을 분리하는 경우도 있다. 그렇다면 DB 작업이 필요한 xxRepository에서 엔티티와 도메인의 변경 작업이 필요하다. 누군가는 이런 작업이 너무 불편하지 않냐고 할 수 있는데 정답은 없다. 외부 DB환경에 구애받지 않으며 비지니스 로직에 집중할 수 있는 부분은 장점이다. 또한 주요 비지니스 로직에서 JPA의 더티체킹을 활용할 수는 없겠으나, 오히려 직관성이 장점이 되어 JPA의 영향도에 너무 불안하지 않고 코드를 작성할 수 있는 편안한 환경이 된다. 처음에야 JPA가 너무 편했지만, 최근에는 JPA를 분리하는 방법을 고민하는 글들이 많이 올라온다고 한다. 최근 몇년 간 서비스가 고도화되고 도메인이 복잡해지면서 굉장히 혼란을 겪는 프로젝트들이 많아서가 아닐까 생각해본다.