Spring MVC

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

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

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

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

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

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

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

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

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