도메인 주도 설계란 무엇인가? (Domain Driven Design Quickly)

전 회사 CTO 님과의 스터디 교재이다.

백엔드 개발자들은 필참이였고 나머지는 선택참여였다.

 

동료 백엔드 개발자분이 개발자의 마음가짐을 바로세우는데 도움이 되는 스터디라고 추천해주셔서 나도 중간부터 참여헀다.

 

정말 그랬다.

 

이 책을 읽으면서 지금까지 일을 잘못 하고 있었다는 생각이 들었다.

GM팀과 우리팀 개발자들은 서로 다른 곳을 바라보고 있었던 것 같다.

그리고 공유커널, 고객-공급자 패턴등을 읽으면서 지난 우리팀과 굉장히 유사하다고 생각했다.

스터디를 추천해주신 백엔드 개발자분께서 디렉토리 구조를 도메인별로 나누자고 하셨는데, 이것도 DDD였다는 것을 뒤늦게 알았다.

그분은 백엔드, 프론트 모두 동일한 이해를 가지고 유관부서들과도 동일한 용어를 사용해야 함을 강조하시던 분이다.

실제로 DDD의 개념을 알고 말씀하셨던것이냐고 여쭤봤는데 그렇다고 하셨다.

 

또 한편 프론트엔드 개발을 어떻게 DDD에 녹여낼 수 있을까? 라는 궁금증이 생겼다.

디렉토리 구조 나누기정도 밖에 떠오르지 않는다.

 

기술적인 내용은 결국 기승전 테스트코드였다. 테스트코드를 통해 사이드이펙트에서 프로젝트를 보호할 수 있다는 내용이 많았다.

 

전 CTO님도 테스트 코드를 작성하는데 가장 많은 시간을 할애한다고 하셨다. 그만큼 요구사항에 집중한다는 뜻이다.

 

요구사항은 유관부서들과 함께 제품을 발전시키기 위한 인수테스트이다.

 

개발자가 일하는 방식이 지난 십수년간 많이 변화했지만, 여전히 변하지 않는것은 개발자가 사람들과 소통하는 과정의 중요성이다.

 

유관부서와 개발팀이 서로 같은곳, 그리고 올바른 곳을 바라보아야 프로젝트 또한 올바른 방향으로 순항할 수 있다.

 

이 DDDQ는 개발자가 유관부서와 일하는 마음가짐을 어떻게 갖고 있어야 하는지 알려준 책이다.

 

CTO님께서 이 책은 DDD의 시작에 불과하다고 말씀해주셨다.

 

더 나은 개발자가 되기 위한 동기부여가 크게 되었다.

 

---

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."