회고
PR 진행중일 때 이후 작업
PR의 단위를 작게 하다보니 PR이 진행중인 브랜치의 데이터가 필요할때가 자주 있었다. 그럴때 어떻게 처리를 할 수 있을지 고민해보았다.
- Develop 브랜치가 아닌, 진행 중인 브랜치에서 새로 분기하여 작업하고, 앞선 PR이 완료된 후 Develop 브랜치와 병합 처리한다.
- 작업 중 코드 중복 사용이나 컨플릭트 발생을 예정하고, 사전 논의와 적절한 조치로 범위 안의 충돌을 해결한다.
일정 조율
- 기본 프로젝트 구현 목표 기본적인 프로젝트 구현을 일요일까지는 완료해야 월요일에 통합 테스트를 진행해서 간단한 후속 조치를 취할 수 있다.
- 그렇게 진행이 되어도 발표 자료를 준비하기 위해 몇시간 밖에 주어지지 않아 데드라인에 맞춰 작업이 필요하다.
TSID와 JavaScript 정수형 한계 문제
TSID 타입은 64비트로 사용 가능하지만, JS에서 정수형은 52비트까지만 지원한다는 정보를 보고 팀원분께서 말씀해주셨다. 이를 해결하기 위해 DTO에서 문자열 타입으로 처리하고, 컨트롤러에서 Long.valueOf(), String.valueOf()로 타입 변환 처리를 하는 방안을 고려해보기로 했다.
팀 진행사항 관련 튜터님 피드백
디테일과 일정간의 균형
하나의 공유 테이블을 만들어 팀 내에서 아이디어를 추가 및 관리하는 방법을 추천한다. 중요도와 우선순위에 따라 작업을 조율하면 디테일과 속도의 균형을 맞추는데 도움이 될 것 같다. 일단 현재 프로젝트는 MSA 설계가 가장 중요한 요소이므로, 이에 중점을 두고 작업하는 것을 잊지 않았으면 좋겠다.
팀 내 기술 공유
디테일한 내용을 조사한 후, 팀 내 기술 공유를 형식적으로 진행하는 방법도 좋다. 실제 회사에서도 기술 공유는 중요한 협업 방식으므로, 좋은 경험이 될 것이다.
DDD패키지 구조에서 DTO, 튜터님 피드백
VIEW와 CONTROLLER 간의 DTO
클라이언트와의 데이터 통신을 담당하고, presentation 계층의 request와 response 패키지에 위치한다. 클라이언트와 상호작용에 필요한 데이터만 포함하여 설계한다.
Application 내부에서 사용하는 DTO
엔티티(Entity)와 분리된 데이터 전송용 객체로, 계층 간 의존성을 줄이고 데이터를 안전하게 전달하기 위해 사용된다. 엔티티는 영속성 컨텍스트와 연결되어 있기 때문에 다른 계층에서 직접 참조하지 않도록 설계해야 한다.
Application DTO 설계 시 고려 사항
-
엔티티와 필드가 동일하지 않아도 된다. 데이터베이스의 컬럼이나 엔티티 구조에 직접적으로 의존하지 않기 때문에 특정 요구사항에 맞는 데이터만 포함하면 된다.
-
필요한 필드만 선택적으로 포함한다. 목적에 맞는 필드만 포함하는게 불필요한 데이터 전송도 하지 않고 명확합니다.
-
하나의 엔티티를 기준으로 여러 개의 DTO를 생성할 수 있다. 동일한 엔티티를 기준으로도 사용 목적에 따라 서로 다른 DTO를 설계한다.
-
파라미터의 수가 적다면 DTO를 굳이 사용하지 않는 것이 더 직관적이다. 단순한 API에서 두세 개의 값만 주고받는다면 DTO를 생략하고 메서드 파라미터로 직접 처리하는 것이 명료하고 오버헤드를 줄일 수 있습니다.
