DDD와 JPA에 대해서 알아야 하는 이유

웹 기술에 JPA 표준기술과 그 구현체인 하어버네이트가 있다.

그리고 DDD(Domain driven design) 도메인 주도 설계가 있다.

DDD나 JPA에 대해서 모른다고 해도 개발하고 구현을 하는데는 아무런 문제가 없다.

내 대부분의 경력 또한 두가지를 모르고 개발을 해왔고, DDD와 JPA에 대해서 잘 알고 있는 사람도 많지 않다.

그리고 이런 부분에 대해서 좋게 평가를 해주는 관리자도 많지 않으며, 

어떤 관리자는 왜 팀원들이 모르는 JPA기술을 혼자만 사용했냐고 할지도 모른다.

어떤 관리자는 왜 기존의 설계와 다른 DDD라는 방식을 썼냐고 반문할지도 모른다.

가끔 나 스스로도 생각을 한다.

왜 JPA를 사용하려 하는걸까? iBatis와 myBatis로도 충분히 개발이 되는데?

왜 DDD를 사용하려 하는걸까? 기존의 컨트롤러, 서비스 구현체(또는 BO 구현체 등), VO(또는 DTO 또는 Map)을 이용한 방식이 깔끔하고 익숙한데?

내 경험으로 비추어 내가 왜 DDD와 JPA에 대해서 공부하고 사용하려 하는지 얘기를 해보겠다.

PRO-C 이야기

잠시, 오래전 이야기를 해본다.

내가 신입으로 회사에 입사했던 시절 잠시 PRO-C를 개발했다. (나는 JAVA개발을 하고 싶었지만 잠시 업무를 맡게 되었다.)

PRO-C는 모르는 개발자들이 많은데, 일반적인 C언어에서 DB 프로그래밍을 가능하게 해놓은 것으로서 금융권에서 아직도 대부분 사용을 하고 있다. 

그런데 이 PRO-C는 미들웨어 위에서 돌아가는데 이 미들웨어가 복잡한 처리는 모두 해주고

개발자는 오직 비즈니스 로직만을 작성하면 된다. 그런데 이 비즈니스 로직이라고 하는 것도 트랜잭션 내에서 데이터 CRUD 작업을 절차적으로 하는 것뿐이다. 비즈니스 로직만을 작성하면 된다는 장점이 있지만, 반대로 시스템에 대해서 설계할 내용이 없다보니 개발자의 역량이 뛰어나지 않아도 되고 DB에 대해 잘 알고 쿼리만을 잘 작성하면 되었다.

업무를 맡고 있던 동안 내가 하고 싶던 객체지향 프로그래밍, 자바, 디자인 패턴 등의 일들을 할 수가 없어서 많이 힘들었다.

그래서 업무 내에서 할 수 있는 DB에 집중했고 DB쪽 쿼리 분석이나 튜닝 등의 공부에만 집중할 수 밖에 없었다.

자바 이야기

내가 잘하고 하고 싶어했던 자바 개발 업무를 하게 되었다.

웹 개발시에는 회사에서 말로만 듣던 스프링을 사용하게 되었다.

스프링 프레임워크를 사용하는 것은 기존에 JSP 모델2나 싱글톤 패턴을 많이 사용하던 기존의 방식과는 많이 달랐다.

처음에는 스프링 프레임워크에 대해 정신없이 공부를 하다가 시간이 흘러갔는데

몇년이 지나면서 나는 묘하게 PRO-C 때와 같은 고민이 들게 되었다.

어느 프로젝트에서던지 웹에서는 대부분 컨트롤러, 서비스 구현체, DAO 구현체, VO(또는 DTO)를 만들고

중요한 비즈니스 로직은 서비스 구현체 또는 BO 구현체에 모두 넣었다.

나름대로 역할을 분리해서 다른 클래스들을 이용하기도 하지만 핵심 비즈니스 로직은 모두 서비스 구현체에서 처리를 하는게

약간 다르지만 PRO-C 때의 절차적인 방식과 크게 다르지 않게 느껴졌다.

게다가 간혹 중요한 비즈니스 로직을 쿼리를 통해서 구현을 하게 되면

시스템의 핵심이 결국 DB에 있게 되고 자바 프로그램은 결국 DB를 위한 껍데기로 느껴져버렸다.

(간혹 로직을 DB 프로시져 등에 담는 경우도 보았다. 이건 정말 절망적이었다..)

나는 객체지향 프로그래밍을 하고 있는걸까? 의문이 들었다.

객체지향 5원칙 SOLID, 객체지향의 4대 특성, 자바 EE 디자인 패턴들에 대해서

공부하고 알고 있지만 이것을 제대로 사용하고 있는 것일까란 생각이 늘 떠나지 않았다.

JPA (Java persistance API)

Slide Share에서 김영한님의 자료들을 보면서 JPA에 대해서 알게 되었다.

하이버네이트는 알고 있었지만 자료들을 보면서 새롭게 와닿았다. 

iBatis, myBatis를 사용하면서 늘 지겨운 쿼리 작성이나 문제점에서 해방될 수 있었다.

게다가 Spring DATA JPA는 최고라고 생각되었다.

그런데 문득 JPA와 ORM의 장점에 대해서 보던 중 "DDD 개발을 가능하게 해준다."라는 문구가 들어왔다.

DDD (Domain driven design)

도메인 주도 설계는 2006년 에릭 에반스의 책을 통해서 이슈가 되었다.

스프링이 DDD를 개발을 지원하려 만들었다고 말이 나왔을 정도였고, 스프링 개발 또한 도메인 주도 설계를 통하여 이루어졌다고 한다.

처음 DDD를 알게 된 것은 다른 사람이 DDD 공부를 하는 것을 보고 알게 되었다.

그 당시 나는 참 쓸데없는 걸 공부한다고 생각하였다.

그런데 시간이 지나서 DDD에 대해서 알게 되고 책을 보면서 나는 DDD가 내가 갖고 있던 갈증을 해소해 줄 방법 같다고 여겨졌다.

기존 서비스나 BO에 비즈니스 로직을 담던 방식은 대부분 잦은 수정을 하게 된다.

객체지향 5원칙에도 늘 맞지 않고, 비즈니스 로직이 복잡해질수록 늘어가는 방어 로직과 사이드 이펙트로 인하여 유지보수가 어려워진다.

DDD는 복잡한 비즈니스 로직을 도메인 모델에 담고 복잡했던 로직을 쉽게 풀어 나간다.

그 풀어나가는 방식을 보다보면 객체지향 5원칙에 맞아 들어가고

초기 설계를 할 때도 또한 도메인 모델을 기반으로 UML을 그리다보면 명쾌하고 간략해진다.

기타

JPA를 쓰다보면 핵심 로직을 DB 쿼리에 두지 않고, 자바 로직으로 많이 옮겨오게 되는데 이 부분에 대해서는 나도 간혹 고민이 된다.

DB를 통해서 한번에 처리할 수 있는 쿼리나 쿼리를 통하는게 성능이 더 좋을 경우가 있는데

이것을 무조건 자바 로직으로 처리해서 성능을 떨어트리는 것은 좋은 방법이 아닌 것 같다.

그런데 쿼리를 통하려고 하다보면 Native Query를 사용해야 하는데

그럴때는 또 iBatis와 myBatis만 한 것이 없다.

(같이 병행해서 사용하는 방법도 있지만 그러고 싶지는 않아서 늘 고민이 되는 부분이다.)