Mybatis 프로젝트에 도메인주도개발 적용

Su hwan Choi·2022년 12월 18일
0

결론은 도메인주도개발에서는 ORM(hibernate-framework)를 적용하는 것이 효율적이다.
Hibernate-framework를 적용하지 않으면 DB를 처리하는 부분에서 직접 작성한코드가 들어간다.
문제는 이 코드가 굉장히 많아진다는 것이다.

  • 조회기능은 Mybatis의 참조 조회기능을 사용하여 조회가능했다.
  • 그러나 추가, 수정, 삭제 등의 기능에서 도메인의 구조가 테이블구조와 일치하지 않는 경우 이를 중재하는 Mapper가 필요했다.
    • Mybatis를 통해 이 Mapper를 만들게 될경우, Mybatis가 있음에도 DTO, XML 등이 추가로 생성이 필요했다.
    • 이 생성은 어찌보면 당연한 것이었다. DB테이블과 도메인구조를 설명하는 파일(XML)과 이를 저장할 DTO를 지정해주는 것이 개발자의 역할이고, Mybatis는 그 후의 쿼리 실행, 트랜잭션 관리 등을 담당하는 프레임워크이기 때문이다.
    • 원래 계획은 도메인객체를 처리하는 Repository 의 인터페이스를 만들고, 그 구현체를 직접 구현하는 것이었다.
    • 하지만 이 리팩토링 작업의 본래 목적은 복잡한 클래스관계를 줄이고, 경계를 명확히 하는것이 목적이었기 때문에 작업을 더 진행할수는 없었다.

그렇다고 완전히 얻은것이 없지는 않았다.

  • 이 작업까지 같이 진행한 다른 개발자들과 공통되는 도메인 지식을 만들었고
  • 기술적으로는 테스트가능한 도메인코드가 만들어지고, 추가 개발도 이 코드를 기반으로 만들어질 수 있었다.

마무리

이 내용을 정리하며

고민을 많이 했다. 결론만 놓고보자면 관점에 따라서는 실패하고, 굉장히 당연한 내용의 리팩토링 작업이기 때문이다. 요즘 이른바 대세기술로 손꼽히는 kafka 라던지, MSA… 에 관한 내용도 아니고, 그렇다고 처리 결과자체를 비약적으로 향상시키지도 않았다.
오히려 당연히 해야되는 것들을 처리한 내용이고, 모두다 알고 있는 것들을 적용한 내용이라고 볼 수도 있다.

그럼에도 불구하고

내가 이 내용을 블로그에 정리한 이유는, 위 리팩토링의 결과 자체는 관점에 따라 보잘 것 없다고 할 수도 있겠지만 리팩토링이 진행되는 과정에서 팀 내의 다른개발자들과 같이 개발을 진행하는 경험을 잊고 싶지 않았다. 입사한지 1년쯤된 주니어개발자와 대략 3년(정확한 연차는 모르고 대략 그정도라고 알고 있다)정도 된 개발자와 같이 진행했는데, 나를 포함한 세명의 개발자가 서로 코드리뷰와 페어프로그래밍을 진행하며 차근차근 진행했다.

이 과정의 좋은점은 주니어개발자의

질문에 대해 실제 같이 작업하는 코딩으로 답을 찾을 수 있다는 것이라 생각한다. 그 과정에서 나도 타인에게 설명하기 위해 좀더 개념을 명확히 하게되고 듣는 사람도 말이 아닌 실제 코드에서 정답을 찾게된다.

예를 들어 DTO 이슈에서는

구글을 뒤져보거나, 혹은 개발서적을 찾아보면 쉽게 답을 찾을 수 있다. 문제는 그 답을 어떻게 나의 작업하는 프로젝트에 적용할 것인가 이다. 구글링으로 나오는 정답들은 좋은 내용이 많지만, 일부 내용들은 아주 간단하고 명확한 예를 들어 설명한다. 책또한 마찬가지다 책의 목적은 내용을 설명하는데 있기 때문에 설명하는 내용을 파악하기 쉬운 예를 들게된다. 결국 내가 설명하고, 적용하지 않으면 어떤 지식이든 책의 내용을 암기하는 수준으로 멈출 수 있다고 생각한다.

단위테스트에 관한 부분에서도

같이 개발했던 3년차 개발자와 같이 진행하면서 단위테스트란 어떤 것인지, 얘기를 충분히 하고 진행했다. 토론에서 참여자가 적어지면 집중도가 올라가고, 깊은 얘기를 할 수 있게 된다. 이 과정이 필요하다 생각한 이유는 단위테스트와 같은 내용도 개발자마다 경험한 내용이 다르기 때문에 단위테스트도 각자 다른걸 생각할 수 있다. 그리고 그 다른 개념을 서로 하나의 프로젝트에 적용해야 하기 때문에 서로 다른 개념의 차이를 짚고 넘어 가는게 중요하다 생각한다.

그리고 나와 다른 실력의 개발자들과

함께하는 것은 다양한 관점에서 접근하는 것을 배웠다. 어떤 한 이슈에 매몰되어 다른 관점을 보지 못할때, 내가 생각하지 못한 질문을 던지며 개발을 진행해왔다. 이 부분은 나 혼자 개발하면 얻을 수 없는 효과일 것이다.

지금 생각해보면

대세기술을 적용하지 않고 오히려 환영받지 않는 기술(Mybatis등..)을 적용한 내용이지만 기록으로 남기는 이유는 저 과정에서 프로젝트는 점차 나아지고 있다는 믿음과 나 혼자 하지 않고 팀 내의 다른 개발자들과 같이 진행하는 상황에서 개발했기 때문이다.
위와 같은 개발이 내가 생각하는 프로젝트개발, 협업 의 뜻이라 생각한다.

1개의 댓글

comment-user-thumbnail
2024년 4월 4일

안녕하세요. 14년차 개발자입니다. mybatis는 과거부터 지금까지 환영받는 기술입니다. ibatis부터 mybatis까지 그리고 최근까지도 제가 14년간 사용했던 기술입니다. hibernate는 과거에도 있었으나 꽤나 오랫동안 사용되지 않은 이유가 있습니다. JPA는 그냥 인터페이스인데.. 결국은 hibernate입니다. 많은 쿼리들을 작성해야하는 노가다가 존재하나 훨씬더 직관적입니다. JPA로 쿼리 튜닝하는건 생각보다 어려운 일이죠. 내가 손으로 직접 바꾸면 되는걸 숟가락이나 젓가락을 사용해서 바꾸려고 하니 어려운겁니다. JPA가 몇년전부터 스프링진영에서 채택되어서 뜬거같은데요. 갠적으로는 추천하지 않습니다. 컬럼하나 바뀌면 쿼리 다고쳐야하는게 불편한거 아니냐 하시는데요. 쿼리는 툴을 사용해서 바꾸면 금방 바꿉니다. JPA는 여러가지상황들을 객체관점에서 생각해서 고쳐야하는 단점이 존재하죠. JPQL이나 queryDsl이 나왔으나 공부할양은 많아지고, 컨트롤하기 어려운건 사실입니다.
DB가 버전업되서 먼가가 추가되고, 먼가가 변경되면 SQL쿼리는 바로 적용가능하나, 중간매개체인 숟가락이나 젓가락(여기선 hibernate구현체)이 개발안되면 당장 적용하기 어려운 단점도 보입니다.

답글 달기