Product Adapter: DataAccess PR 작성, 알고리즘 문제풀이, 독서

드디어 작성한 3 번째 PR

오늘은 드디어 3번째 PR을 작성했다.(참 오래걸렸다..) 예상하지 못한 부분에서 문제가 많이 발생해서 작은(?) PR 임에도 상당한 시간이 소요되었다. 아침에는 독서 및 공부 후, PR 작성을 시작했는데, 역시나 생각을 정리하는 것이 어렵다. 그래도 이전보다는 많이 나아졌다.(고 느낀다 ㅎㅎ) 첫 PR과 지난 PR에서도 PR의 단위가 너무 크다는 피드백을 받아 이번에는 더 작은 PR로 나누어 보았다. 아직도 다소 큰 것은 아닐까? 하는 생각이 들지만.. 리뷰해주시는 분들이 리뷰하기에 불편하지 않았으면 좋겠다.

 

Feature/product adapter: DataAccess by KEEMSY · Pull Request #3 · KEEMSY/shoes-ordering-system

 

---

Product Adapter: DataAccess PR 작성

 

이해를 돕기 위해 지금 개발된 모습과, 개발될 영역을 표시해 보았다.

 

나는 이번에 Adapter 영역 중 out port 의 ProductRepository 구현체인 PersistanceAdapter 를 구현했다. 지난 Member 도메인에서는 MemberRepositoryImpl 이라는 이름으로 개발된 모듈과 같은 기능을 담당한다. 지난 Member 도메인 개발 이후, 계속된 클린아키텍처에 대한 공부를 진행하면서, MemberRepositoryImpl 작명이 Adapter 라는 것을 쉽게 파악하기 힘들 것 같다는 생각이 들었다.(비록 패키지로 나 어댑터야! 하고 외치고 있긴 하지만 말이다.)그래서 이번에는 이름에서부터 Adapter 임을 뿜뿜했다.

 

member 도메인에서의 MemberRepositoryImpl

 

ProductPersistanceAdapter 는 다음의 특징들을 갖고 있다.

 

• ProductRepository 를 구현한 구현체이다.
• JPA Repository 와 Querydsl을 함께 사용한다.
• 데이터 영속성 계층으로서, 도메인 객체와 관련된 영속성 객체를 구현하여 사용한다.
• 애플리케이션에 의해 호출될 뿐, 애플리케이션을 절대 호출 할 수 없다.
• ProductPersistanceAdapter 가 계약을 만족하는 한, 도메인에 영향을 미치지 않고서 코드를 마음껏 수정 할 수 있다.

 

---

보충 반복 설명: 구조 및 의존성에 관하여

지난 많은 매일 TIL 에서 왜 이런 구조를 갖게 되었는가?를 이야기 한것같다.(하도많이 고민한 부분이라 아닐수도있다..) 많은 중복이 될 수 있지만, 다시한번 이야기를 해보겠다~!(반복 복습 정리!)

 

 

Concrete Repository 는 PersistanceAdapter 를 의미한다.

 

도메인 계층에서의 각 서비스는 유스케이스를 구현하기위해  Repository(영속성 계층)을 호출한다. 이는 당연하다. 하지만 기존의 MVC 패턴의 계층형 아키텍처에서는, 의존성의 방향이 도메인 방향이 아닌 영속성 계층을 향하게 된다. 이는 비즈니스에서 가장 중요한 비즈니로규칙(도메인) 이 변경될 이유가 늘어남을 의미한다.(도메인 로직이 변경될 경우 + 영속성 계층이 변경될경우)

 

이 잘못된 의존성을 뒤집기위해 도메인 계층에서는 Repository 인터페이스를 이용하게 된다. 인터페이스에서는 각 계약을 명시하며, 영속성 계층에서는 이 명세를 구현함으로써, 도메인 계층에 의존하게 된다.

 

 

---

이렇게 하면 무엇이 좋을까?

 

이렇게 각 계층을 분리하고, 의존성의 방향을 도메인을 향하도록 한다면, 계층의 역할과 경계를 분명하게 하여 각 계층이 독립적으로 확장 및 수정할 수 있게된다. 그리고 무엇보다 도메인 계층을 보호할 수 있게된다.(도메인은 왕이다!)

 

 

---

영속성 계층의 확장: JPA 와 함께하는 Querydsl

 

ProductPersistanceAdapter의 생성자 부분

 

그리고 이를 몸소 경험하기 위해, 현재 유스케이스가 (상당히) 적음에도 불구하고 JPA 만 사용하려던 계획에서, Querydsl 도 함께 사용하는 방법으로 확장하였다. 간단한(?) 추가이지만 Java 를 사용하며 처음 만드는 나로써는 (크지만 작은) 도전이다!

 

 

내가 생각한 JPA 와 Querydsl 의 역할

 

나는 JPA과 Querydsl의 역할을 나누었다. 처음에는 JPA를 걷어내고 Querydsl 만을 사용하고자 하였는데, 이럴경우 정말 간단한 CRUD 조차 모두 다시 만들어야하는 귀찮음과.. 보일러플레이트를 만들것으로 생각되어 JPA 와 Querydsl을 역할을 분담하여 함께 사용하기로 하였다.

 

하지만 앞서 이야기 했듯이, 현재는 유스케이스의 수가 (많이)한정되어있어 나눈 역할 별로 완전히 쿼리를 분류하지는 못하였다. 하지만 향후 기능이 추가될 때, 식별된 역할에 따라 보다 명확한 책임 분담으로 개발이 진행 될 것이다.

• 개발간 신규 기능으로 동적쿼리의 추가는 Querydsl 에 추가될 것이다.

 

 

---

고민

 

그런데 계속된 PR을 진행하면서 고민이 되는 부분이 있다. 프로젝트 의 구조 부분이다. 나는 프로젝트를 진행하기 전, 분석과 설계를 진행하면서 프로젝트의 목표를 설정하고, 이를 달성하기 위한 설계를 진행했다.

 

• 목표: 표현력이 강한 아키텍처, 기능개발이 이뤄질 때, 어느곳에 해당 기능을 추가해야할 지 명확한 아키텍처 를 만들고자 하였다.
• 결정: 도메인형 아키텍처 구조설계, DDD 기반의 프로젝트 설계, Clean Architecture(Ports and Adapters)를 적용한 프로젝트 설계
• 결과: 계속된 아키텍처 구조에 대한 질문

 

결과적인 부분은 당연하고 정말 감사한 부분이다. 그런데 한편으로는 이것이 내가 목표로 하는 것에 맞는 것인가? 하는 고민이 많이 하게된다. 결정을 하고 해당 부분을 공부할 때 나는 스스로 많이 질문하고, 답하며 공부한 것을 생각하면, 이정도의 질문은 당연하다 생각이 들면서도, 고민을 하게만든다.

 

이 부분은 리뷰 부분에서도 존재하여, 이것을 주제로 한번 이야기를 해볼 수 있다면 해봐야겠다.

 

---

독서 공부: 도메인 주도 설계로 시작하는 마이크로 서비스 개발

 

언제나 그렇듯 계속해서 매일 꾸준하게 책을 보며 공부하고있다. 책의 내용을 보면 볼 수록 데브옵스의 중요성을 느끼게 되는 것 같다. 나는 지금까지 내부 아키텍처에 집중하여 공부를 진행했고, 외부 아키텍처(인프라) 적인 요소에 대한 지식이 많이 부족함을 느끼게 되었다.

 

• 외부 아키텍처: 인프라 영역과 플랫폼 영역, 애플리케이션 영역에 있는 구성 요소 및 그것들의 관계를 정의하는 것을 말한다.(= 서비스가 운영되는 환경을 의미한다.)
• 내부 아키텍처: 비즈니스가 실행되는 비즈니스 애플리케이션을 의미하며, 서비스가 제공하는 API, 비즈니스로직, 이벤트발행, 데이터 저장 처리 등을 어떻게 구조화 해야하는가에 대한 내용을 포함한다.

특히 인프라를 구성한 경험의 부족이 많이 부족한 것 같다. 클라우드 가상 인스턴스를 관리하는 경험이 개인 프로젝트, 로컬 개발환경 구성뿐이 없다.. docker 를 활용한 컨테이너 환경을 구성했지만, 컨테이너 오케스트레이션을 직접 실무에서 경험해보지 못했다. 그저 로컬에서 혼자서 공부해봤을 뿐..

 

그리고 이번 책을 보며 알게된 것이, (클라우드) 인프라의 장점을 이용하면, 애플리케이션이 인프라와 같은 구조가 되어야한다는 것이다. 소프트웨어 아키텍처를 공부하면서, 고민이 되었던 부분이, 아키텍처가 (지금생각해본다면)인프라와 같았다. 오픈소스 및 다양한 (클라우드)서비스들을 활용하여 아키텍처를 구성하기에, 내가 (클라우드)서비스에 집중을 해야하는 것인지, 아니면 코드 수준의 기술에 집중해야하는것인지 고민이 됬던 적이 있다.

 

이게 정답은 아니겠지만, 친구의 멘토링 시간을 통해 답변을 들을 수 있었는데, 해당 멘토님의 답변은 서비스를 알고 있는 것이 더 중요한 것이라 생각하신다고 말씀하셨던 기억이 난다. 그리고 지금으로 돌아와 본다면, 결국 인프라를 알아야한다. 인프라가 결국 아키텍처가 되는 듯 하다.

 

재밌다. 아직 인프라 관련된 책(지식)을 많이 보지 못했지만, 과연 공통된 문제를 어떤식으로 해결해 나갈지, 어떤 패턴이 존재할지 궁금하다. 어서 빨리 이 책을 공부하고(이전에 프로젝트도 마무리하고) 외부 아키텍처를 공부해야겠다.

 

---

알고리즘 문제풀이

 

요즘 매일 꾸준하게 코틀린으로 기초 알고리즘 문제를 풀이하고 있다. 기초적인 문제들이라서 아이디어 자체는 간단하게 풀리지만 이를 구현하는 방법을 많이 알게된다. 문제와 알게된 내용을 정리하고있는데, 진짜 초심자 그 자체가 된 것 같다. 문제 해결을 위한 효율적이고 아름다운 부분과 개발을 진행하며, 아름다운 코드는 조금 차이가 존재하는 것같다.(아니면 내가 그런 강박이 있는 것일지도..)

 

---

월요일이 정말 정신없이 지나갔다. 생각을 표현하는데 하루가 다갔다. 내일은 PR피드백에 대한 스스로의 리뷰와 다음 Messaging 을 개발할 수 있도록 해봐야겠다. 아좌좌~~