프로젝트를 진행하면서 느낀 레이어 분리 와 DDD 의 중요성
개요
기능을 개발하며 한곳에 엄청난 것을 때려 넣다 보니 수정도 힘들고 무엇보다 리뷰가 너무 힘들었습니다.
혼자 할 때는 별문제가 없습니다. 사실 혼자 하는 제 자신이 저만의 규칙으로 잘 정리할 거거든요.
문제는 협업을 하는 순간 저만의 규칙이 아닌 코드가 보이게 되고 협업자와 서로 마이웨이를 가면 코드 리딩이 너무 어려워집니다.
이를 해결하기 위해서 여러 글들을 읽어보고 느낀 점입니다.
협업에 대한 문제
혼자 할 때는 규칙이 없어도 내가 생각하는 이상적인 구조로 파일을 배치하고 개발해 나갔으며 리펙토링이 필요한 시점에도 내가 모든 것을 파악하고 있기 때문에 리펙토링에 유연했다.
협업을 하면서 나와 생각이 다른 엔지니어와 일하게 되었으며 아키텍처를 아무리 설계해도 제 생각과 다른 코드가 생성된다는 것을 경험할 수 있었습니다.
왜 DDD?
그러다 보니 코드 리뷰도 어려워지었고 리펙토링을 하고 싶어도 이해가 안 된 코드도 있고 의도가 모호한 코드와 더불어 수정 시 산탄총 수술(Shotgun Surgery) 과같이 Side Effect가 거대해서 수정하기가 어려웠습니다.
결국 보면 모호한 규칙과 더불어 App을 만드는데 필요하게 Domain 분리를 안 했기 때문이라고 결론이 나왔습니다.
저는 처음에 Domain의 단위를 RDBMS의 최소 엔티티 단위인 Table로 생각하고 진행하였습니다.
그렇게 진행하던 도중 잘못 생각했다는 시점은 생각보다 빨리 만날 수 있었는데 Table이 여러 개의 Table와 릴레이션 된 경우 처리가 복잡해졌습니다. 애초에 Table 단위로 레이어를 분리하여 로직을 작성한다는 것이 어려웠습니다. Table에서 여러 Table을 참조해서 데이터가 가공되어야 하는데 그것이 불가능했기 때문이었습니다.
결국 생각이 돌고 돌아 PO 및 엔지니어가 더불에 생각하는 처리의 단위가 Domain이라는 것을 알게 되었고 Domain 위주 개발을 위해서 DDD를 도입해야겠다고 생각했습니다.
저는 처음에 DDD가 대단한 것인 줄 알았는데 공부를 해고 찾아보면 느끼는 점으로 지금 제가 이전에 겪었던 문제로 데이터 주도 개발을 하면서 겪은 문제로 도메인 단위 로 개발하는 것이 가독성 및 기능 개발에 유리하다는 것을 알았습니다.
MSA를 할 때 Service 단위를 어떻게 찢어내기가 고민인 것처럼 DDD도 어떻게 Domain 단위로 찢어내지가 고민이더군요.
이에 대한 답은 기능 개발 혹은 스키마를 설계하다 보면 자연스럽게 따라오는 Domain 단위에 찢어낼 수 있었습니다.
결국 제품의 형태에 맞게 자연스럽게 Domain이 정해진다는 것을 느꼈고 앞으로 Domain은 변경될 것입니다. Domain이 변경되면 그 이유에 맞게 팀과 엔지니어는 이해할 수 있을 것입니다.
이게 보니까 DDD가 빛을 보려면 제품하는 형태의 특이한 Domain이 있어야 공감이 되면서 분리가 되는 것이라 Todo와 같이 기능 가짓수도 적고 Common 한 Domain에서는 굳이 DDD가 필요 없을 것입니다.
특이한 Domain을 예시로 글로 설명하기 어려워서 대부분의 인터넷 글을 그나마 Common 하면서 어려운 Domain인 쇼핑물을 예시로 들더군요.
사실 저는 해당 프로젝트 이전 DDD에 공부할 때는 어려운 Domain을 건드려본 적도 없고 인터넷 대부분의 예시인 쇼핑물을 만들어본 적이 없어서 깊은 공감보다는 가볍게 공감하여 넘어갔는데 실제로 프로젝트를 진행하면서 어려운 Domain과 협업을 하다 보니 왜 필요한지 이해하고 사용할 수 있게 되었습니다.
커뮤니케이션도 협업이다
그리고 DDD와 더불어 아키텍처 그리고 협업이라는 것이 문서 혹은 팀에 규정된 것이 아니라 모두가 이해하고 생각하는 것이 중요하다는 것도 느낄 수 있었습니다.
소프트웨어 설계 20년 해보고 깨달은 ‘좋은 설계’의 조건 글을 보니까 아키텍처 같은 것이 팀에서 규정한다고 끝이 아니라 계속해서 커뮤니케이션해 나가는 것도 하나의 아키텍처라는 것이 공감되었습니다.
실제 해보니 아무리 말해도 일정이 밀리고 급해지면 백날 말한 규칙이 다 깨지더군요 결국 처음 개발할 때부터 이해도 있게 규칙에 맞게 개발되어야지 해결될 것이라고도 느낄 수 있었습니다.
왜 레이어를 분리해야 할까?
사실 개발하면서 느낍니다 이거 이렇게 하면 결합도가 너무 커서 확장이 어려울 거 같은데?
그럼 그때 되면 생각하자~ 하고 넘기는데 이제 넘겼던 그 문제가 발생할 때는 기술 부채로써 너무 고통스럽더군요.
이걸 방지하려면 단일 책임 원칙으로 레이어를 분리하면 되는 것이라고 생각합니다.
조금 더 코드 디자인적으로는 순수 함수 형태로 만드는 것이죠.
제 오판이었던 RDBMS의 최소 엔티티 단위인 Table 단위로 시작해서 FE와 BE의 서로 interface는 같겠지 하고 진행했지만 실제 UI를 그리면서 조금씩 달라지는 스키마를 보며 아… 레이어를 더 빡세게 분리해야겠다고 생각할 수 있었습니다.