Spring MVC

springmvc.egloos.com


포토로그


2012/05/15 23:42

에릭 에반스가 말하는 DDD(Domain Driven Design) Domain Driven Design

전 세계 DDD(Domain Driven Design) 그룹을 이끌고 있는 에릭 에반스가 4년의 퇴고 끝에 출판한 도메인 주도 설계에는 마틴 파울러의 다음과 같은 추천사가 담겨 있다.

에릭 에반스는 도메인 모델을 잘 만들어 낼 수 있는 몇 안 되는 사람 중 하나다. 난 이 사실을 에릭과 함께 일하면서 알게 됐는데, 이때가 바로 자신보다 실력이 더 뛰어난 고객을 만나는 것과 같은 멋진 순간이었던 것으로 기억한다. 우리가 함께 일했던 시간은 짧았지만 더할 나위 없이 즐거운 시간이었다. 그 이후로도 우린 계속 연락하며 지냈고, 그래서 난 이 책이 서서히 제 모습을 갖춰가는 과정을 지켜 볼 수 있었다.

기다릴 가치가 충분히 있었다.

도메인 주도 설계란 우리가 지켜야할 많은 원칙들을 성립가능하게 도와주며 개발자의 코드가 많은 시간이 지나도 레거시로 전락하지 않게끔 도와준다. 더불어 개발자와 기획자, 그리고 사용자 간의 원할한 의사소통을 도와주면서 코드를 보다 직관적이고 누구나 이해하기 쉽도록 만들어 낸다. 이러한 도메인 주도 설계의 장점에 대해서 꼭 들어맞는 마틴 파울러의 명언이 하나있다.

"컴퓨터가 이해하는 프로그래밍은 누구나 할 수 있지만 사람이 이해할 수 있는 프로그래밍은 아무나 할 수 없다"

DDD는 아키텍트를 넘어 하나의 언어적인 가치를 띄는 패러다임이며 많은 소프트웨어 엔지니어들이 정복하지 못했던 객체지향적 설계를 담담히 그려나가고 있다.


왜 "Domain Driven Design"인가?

사실 현대의 'MVC 아키텍트'만 가지고도 충분히 좋은 소프트웨어를 만들어 낼 수 있다. 지금까지 많은 소프트웨어가 'DDD'의 설계법으로 접근하지 않았음에도 훌륭한 소프트웨어를 만들어 내었으며 이런 명백한 사실에 근거하여 많은 개발자들이 굳이 'DDD'를 해야 하는지 의문을 품고 자신의 코드를 전환하길 꺼려한다.

물론 위와같은 논리는 어느 정도 타당한 이유라 할 수 있겠다. 이미 'MVC'로 좋은 소프트웨어를 제작할 수 있고 자신과 협업하는 팀원들이 'MVC'로 작업하길 원하는데 혼자 억지를 부리며 'DDD'로 전환하자고 소란을 피워서는 안되지 않은가. 게다가 제대로 설계되지 못한 도메인 주도 설계는 오히려 큰 화(속도가 크게 격감하거나 제대로된 관계 매핑을 하지 않아 이해가 더욱 어려워지는…)를 부를 수도 있고 함께 협업하는 팀원들이 공통된 아이덴티티를 공유하지 않는다면 삼천포로 빠질 가능성이 크다.

그렇다면 왜 "Domain Driven Design"인가? 이유는 간단하다. 현대의 많은 소프트웨어들이 'MVC' 아키텍트를 활용하여 개발함에 따라 공통적으로 발생했던 중대한 문제 때문이었다. 'MVC'는 계층을 효과적으로 분리해내고 역할 간의 협업을 쉽게 해주어 개발의 속도를 비약적으로 향상시켜 주었지만 소프트웨어의 개발이 완료됨과 동시에 기존의 코드를 레거시화(재사용이 불가능한 낡은 코드)시켜버렸다.

많은 개발자들은 공감할 것이다. 기존의 'MVC' 아키텍트로 작성된 코드들은 기능을 향상시키거나 변경하는데 꽤나 까다로운 과정을 거쳐야 한다는 것을 말이다. 테이블에 컬럼이 하나 추가되거나 비교적 간단한 수행연산만 하더라도 코드의 가독성이 너무 떨어지고 추가해줘야할 코드가 너무 많은 탓에 (검증과정에서부터 Model - Controller - View 를 전부 수정해야 한다…) 참 손을 대기가 겁난다.

에릭 에반스는 일찍부터 이런 재사용 불가능한 레거시 코드의 문제의 심각성을 깨닫고 이를 미연에 방지할 수 있는 아키텍트를 완성하고자 노력하였다. 에릭 에반스가 제창하는 'DDD'의 목표는 제법 원대한데, 1년이 지나도 10년이 지나도 계속적으로 재사용될 수 있는 코드를 추구하는 것이다.

참 어찌보면 황당할 수도 있겠지만 도메인 주도 설계의 원리를 파악하고 나면 결코 막연한 것이 아니다. 실제로 스프링 프레임워크는 'DDD'의 설계원칙을 정말 잘 지켜내며 만들었는데, 2년 전에 작성되었던 클래스를 근래에 작성되는 코드가 일절 변경없이 상속하여 확장하는 경우가 비일비재하다.

아직까지 로우레벨 기술이 안정화되지 못한 상황에서 사실 'DDD'는 개발자의 욕심이라고 할 수 있다. 그리고 국내의 'SI' 풍토에서 재사용 가능한 코드는 괜한 밥줄 끊어먹는 소리에 개발기간 연장하겠다는 소리인데 윗선에서 들으면 모가지 날라가는 소리 아니겠는가. 현실을 감안하여 어디까지나 개발자 스스로가 소프트웨어의 완성도를 높이고 지속적으로 발전가능한 상태를 추구한다는 가정하에 'DDD'는 필연적으로 선택되어야할 과제이다.

덧글

  • 지나가다 2012/05/16 10:32 # 삭제 답글

    절대로 딴지걸려고 하는 것은 아니구요, 다만 올리신 글을 읽다가 오해의 소지가 많겠다 싶어 몇자 적습니다.
    우선 MVC를 DDD와 동일 선상에 놓고 비교 하시는데 이 두개의 개념은 서로 장단점을 다툴 성질의 것이 아닙니다. MVC는 말씀하신대로 아키텍쳐에서 비교적 앞단에 대한 개념이고 DDD는 백엔드쪽에 관련된 개념입니다. 즉 서로 대척점에 있는 개념이 아니고 많은 프로젝트에서는 서로 같이 사용하는 일이 다반사입니다.
    두번째, 스프링 프레임워크가 도메인 주도 설계의 원칙을 정말 잘 지켜내며 만들었다고 하셨는데, 스프링 프레임워크는 DDD와는 어떤 특정한 관계가 있거나 염두에 두고 개발을 했거나 하는 그런 프레임웍이 아닙니다. 서로간에 잘 융화될수도 있고 그렇지 않을수도 있지만 스프링과 DDD를 직접적으로 연관시키는건, 글쎄요,, 많이 어색합니다.
  • 거짓말 2012/05/16 11:51 #

    MVC와 DDD가 서로 대비되지 않고 보통 MVC 아키텍트에 DDD가 함께 쓰인다는 것은 잘 알고 있습니다 ^^; 제가 말하고 있는 MVC는 간단한 자바빈 오브젝트와 서비스 계층을 두텁게 하는 Smart UI 형태의 MVC 였는데... 잘못 전달됬나 봅니다.

    그리고 제가 스프링프레임워크가 DDD원칙을 잘 지켰다 함은 DDD에서 요구하는 모델링 중심의 설계를 정말 훌륭하게 소화해냈기 때문입니다. 꼭 DDD라 하여 Value Object, Entity 중심의 설계를 해야 하는 것은 아니라고 생각하기 때문에 스프링의 직관적인 설계와 좋은 모델링 방법은 DDD로 개발함에 있어서 좋은 참고자료가 될 수 있다 생각합니다.
  • 빼빼로 2012/05/25 16:55 # 삭제 답글

    제가 알기론 스프링 2.0 인가 2.5 부터 ~ DDD 방식으로 개발 되었던 걸로 알고 있습니다. ㅇ_ㅇ;
  • 거짓말 2012/05/27 08:12 #

    아 그건 제가 알기론 스프링이 DDD 방식으로 개발되는 게 아니라 스프링 개발진들이 @Configurable이란 어노테이션으로 DDD 아키텍쳐를 지원하는 것을 말씀하시는 것 같습니다 ^^
  • coding8282 2016/12/27 13:43 # 삭제 답글

    저는 최근 DDD를 학습하고 있는 사람인데요, j2ee model보다 DDD 방식이 우월하다는 점에 동감합니다. 다만 DDD를 실제 코드로 구현할 때는 뭔가 괴리가 있다는 것을 깨달았습니다. 예를 들어, 페이징처리나, 성능 이슈 및 모델을 그대로 표현할 수 없는 경우 등이 있네요. 하지만 DDD를 학습할 때 가장 난점은 코걸이귀걸이 현상이 아닌가 싶습니다. 모델이라는 게 사람마다 생각하는 것에 따라 나오는 것이라... 쉽지가 않네요. 그래도 DDD 스타일이 앞으로 나아갈 바람직한 방향이라고 생각합니다.
댓글 입력 영역