”한 번의 실수는 배움이, 두 번의 실수는 실력이 된다.”
→ 개선 사항 추적과 리마인드를 통해 동일한 문제나 같은 실수를 반복하는 결과를 만들지 않습니다.
”경험이 없다면 창조도 없다.”
→ 경험한 것을 기록해두면 더 잘 활용하기 위한 방법으로 연결시킬 수 있습니다.
“I may be wrong.”
→ 끊임없는 회고를 통해 자기객관화를 달성하고, 자신의 실수와 잘못을 인정할 줄 아는 용기 있는 사람이 됩니다.
5주차를 돌아보자.
Chapter2 서버 구축 3주간의 항해 중 마지막 주차이다.
지난 주차에 테이블 설계, 기본 기능 구현, 대기열 초기 구현(테스트와 고도화 필요..), 단위 테스트까지 다 완료하였고,
화요일까지 통합테스트를 반 정도 작성 중이었다. 나름 순항 중이었다고 할 수 있었다.
수요일에 통테를 마무리하고, 목요일에 대기열 구현을 조금 더 고도화하고 회고를 작성하려는 계획이 있었지만 수요일에 팀원 분께서 도메인 모델에 객체를 들고 가야 하느냐, pk를 들고 가야 하느냐에 대하여 화두를 던졌다.
회사 선배한테 여쭤봤더니, 도메인 애그리거트와 강결합, DDD에 대해 간단히 말해주셨다.
순간 생각해보기에 애그리거트를 기반으로 나누는 것이 좋겠다는 생각이 들었고, 이에 대해 많이 고민했다.
그 와중에 처음으로 다른 코치님께 팀 멘토링을 받았는데, 하필이면 운명처럼 코치님의 시각도 애그리거트를 분리해 도메인별 의존성을 낮추고 도메인의 역할을 분리하는 데에 주요한 시각을 가지고 계셨고 이에 대해 많이 말씀해주셨다.
목요일 밤이 과제 제출이고, 이미 많이 진행되어서 난리가 나겠지만
다른 방향성으로 만들어보고 싶었고, 이에 도메인 모델부터 다시 바꾸어 전체적으로 수정하는 작업을 들어갔다.
그리고 그 수정에 정말 비용이 많이 들었다...
Keep
멘토링 받았던 포인트에 대해 숙고해보고, 나만의 그림을 그리는 기준이 더 확실해지고 있는 것 같아 좋다.
애그리거트에 대해 생각해 본 시간이 유의미했다.
결국 서비스는 핵심 기능이 얼마나 잘 돌아가는지가 중요하다.
- 핵심 기능이 본인의 역할의 책임을 다 할 수 있도록 도메인 기능을 잘 분리하여 설계하자.
- 모든 것을 다 갖춘 설계는 없다. 각 장단점이 있다. 내가 해야 할 것은 어디에 집중할 지 스스로 선택하는 것
- 여러 가지를 모두 구현해보며 나만의 기준과 나의 스타일을 찾자.
Problem
초기에 개발 방향성을 잘 생각해서 설계를 잘 해야 할 것 같다. 아직 따라가기에 급급하여 중간에 방향성을 트는 일이 빈번하게 있다.
Try
설계하는 과정, 그림을 그려보고 플로우 차트를 그려보는 과정을 소홀히 하지 말자. 그 시간을 쓸수록 구현 과정은 명확해지고 개발 시간은 줄어든다.
여전히 지식이 부족하다. 구현만 하지 말고 지식 탐구도 하자!
