jrcfore***
2022-04-23

실제 업무에 도메인 주도 설계(DDD)를 적용할 수 있도록 기본적인 DDD의 핵심 개념을 익히고 구현을 통해 학습할 수 있도록 구성한 DDD 입문서
객체지향 개발론, 함수 지향 개발론,절차 지향 개발론 등 수많은 개발론이 있다.
솔직히 개발론이라 함은 그냥 이제껏 쌓여왔던 경험이 누적되어 특정 이름을 중심으로 묶여진 것이리라 생각된다. 특히 막 개발자에 입문한 사람들에게 있어서 새로이 등장한 개발론은 실전 개발에 꼭 적용해야 하는 대상으로써그리고 신봉해야 할 대상으로써 다가가는 부분이 적지 않은 것 같다. 특히 이전에 등장했던 개발론은 더이상 쓸모가 없거나 퇴물로 여겨지는 경우가 많은 것 같다.
필자가 생각건대, 그러한 관점은 본인의 사고의 틀을 확장시키는 데에하나도 도움이 안 될뿐더러 신기술 만능주의라는 잘못된 오류에 빠지는 누를 범하기에 필요충분조건이라 생각된다.
신규로 등장한 이론이 아무래도 각광받는 것은 당연할 수밖에 없단 생각이 들긴 한다. 아무래도 새로이 등장한 이론에는 요즘 개발 트렌드가 반영되었을 것이며 또한 신기술의 동향에 맞춰 구성되었을것이기 때문이다.
하지만 그렇다 하여, 앞서 언급한 것과 같이 이전에 등장했던 개발론들이전혀 쓸모없고 시대에 뒤떨어진 퇴물들이라고는 생각지 않는다. 이전 개발론 들이 있었기에 새로운 개발론이등장한 것이고, 새로 등장한 개발론들이 반드시 모든 개발 상황과 케이스에 딱 들여 맞는 것도 아니기때문이다.
그렇기에 필자는 이번에 리뷰를 진행하게 될 "도메인 주도개발"에 대한 내용을 기존 이론과 비교하며 나의 사견을 밝히기보단, 오로지 도메인 주도 개발이 무엇인지에 대한 관점에서 리뷰를 진행하려 했었고 그리했다.
도메인 주도 개발 이론은 학부 때 많이 배우는 MVC, MVP, MVVM 이론과비슷한 또 다른 하나의 패턴 법이라고 보면 편할 것 같다.
다만, 위의 패턴들은 웹 개발을 할 때에 많이 경험할 수 있는 패턴들이며특히나 회사에 가서 코드들을 보면 대부분의 위의 패턴들을 기반으로 개발되었기에 사전에 알아두면 많은 도움이 된다.
솔직히 학부 때 위 이론들은 그저 책에 쓰여있는 내용일 뿐, 실제로는많이 안 와닿을 수도 있겠다는 생각이 든다. 왜냐하면 대규모 트래픽을 직접 서비스를 구축하여 경험해보기 어렵고 또한 웹 서비스를 개발하더라도 개인의 영역에서 개발되기 때문에 협업의 기회 역시 많지 않기 때문이다.
하지만 그렇다 하더라도 이론을 차치하고 컴퓨터 학문은 실용학인 만큼 꼭 책의 내용들을 직접 실습해 보고 나아가자신만의 서비스들을 개발해 보길 권장한다.
이 책은 우선 구성이 정말 좋은 책이고 또한 저자가 독자를상당히 배려해서 쓴 책임이 한눈에 보이는 책이다.
구성이 좋은 책이라 평한 이유는 책을 읽어 내려감에 있어서 불편한 부분이 없었기 때문이다. 보통 전공서라 함은 내용이 너무 딱딱해서 한 장 읽기도 상당히 버든이 들기 십상이다. 하지만 이번에 이 책을 공부하면서 필자는 단 한 번도 흐름이 멈추거나 중간에 답답했던 적이 없었던 것 같다.
또한 앞서 언급한 것처럼 컴퓨터학은 실용학이다. 따라서 글로만 백날배워봐야 실제 환경에서 코드로 그리고 알고리즘으로 문제를 잘 풀이하지 못한다면 배웠던 이론은 전혀 쓸모가 없게 되는 학문이라는 것이다. 이런 점에서 이 책은 실제 상황과 유사한 예시들을 코드로 풀어가며 독자들에게 설명하고 있다. 이 말인즉슨 위 책의 내용은 독자들이 추후, 혹은 이미 대면하고있는 회사에서 겪게 될 코드 구성과 개발론에 대한 팁들이 잘 녹아들어 있음을 의미한다.
책은 이론에 대해서 그 배경과 저자의 사견을 시작으로 각 상황별 적절한 코드 예와 엔티티 다이어그램, 시퀀스 다이어그램 등을 적절히 사용해가며 친절히 풀어가고 있다.
이 장에서는 이 책의 주 내용이 될, DDD 핵심 개념에 대해서 설명하는 장이다. 또한 이 책에서 앞으로전개하며 사용할 어휘들에 대해 자세히 설명되어 있다.
무엇보다 엔티티와 벨류의 정의가 무엇인지에 대해서 잘 정리되어 있는데, 이부분에 대해서는 필자도 많이 공감 가는 부분이어서 독자들이 꼼꼼히 공부하고 넘어가시길 권장한다.
마지막 부분에서는 각 오브젝트 생성 시에 getter와 생성자의 역할에대해서 설명하고 있다. 왜 객체 정의 시에 getter를남용하면 안 되는지 그리고 생성자의 역할이 얼마나 중요한지에 대해서 잘 나와있으니 이 부분도 꼼꼼히 챙겨가시길 권한다.
챕터 전반의 내용은 도메인 모델을 이용한 개발에 대한 시나리오를 설명하고 있으므로 도메인 지향의 개발 시 어떤부분을 고려해야 할지 그리고 각 레이어별 어떤 구성을 해야 할지 (뷰,서비스, 모델, 인프라)에 대해서 나만의 식견으로 한번 그려보도록 하자.
이 장에서는 "애그리거트"에 대한 이론과 실무 환경에서의 구성에 대해서 설명하고 있다. 보편적으로각 엔티티에 대해서는 웹 개발을 어느 정도 개발해 본 사람들이라면 잘 알고 있는 것 같다. 하지만 애그리거트를어떤 식으로 구성해야 되는지 또한 특정 도메인을 중심으로 어떻게 구분해야 하는지에 대해서는 많은 개발자들이 생소해하리라 생각된다.
필자도 아직 도메인 단위로 엔티티를 구성하고 재조립하여 확실한 도메인 중심의 고립과 분리를 하라 하면 쉽사리모든 규약을 준수하진 못하리라 생각된다.
이 장에서는 이러한 구성법에 대한 팁과 노하우에 대해서 잘 설명하고 있다.
이 장은 응용 서비스 레이어와 표현 레이어에서의 역할을확실히 구분 지어 설명하고 있다. 일반적으로 응용 서비스 레이어를 보편적인 용어로는 서비스 레이어라고통상 사용한다.
서비스 레이어는 해당 서비스 REST-API에 맞는 Service들로 구성하여 목적한 바에 맞는 로직을 구성하는 레이어이다. 이또한 많은 개발자들이 잘 인지하고 있는 사항이지만 정확히 표현 영역과의 구분을 애매모호하게 이해하는 사람들 역시 적지 않은 것이 현실이다.
표현 영역은 사용자의 화면으로부터 입력을 받아서 서비스 레이어에 진입하기 직전 그리고 서비스 레이어에서 모든로직을 끝내고 표현 영역으로 값을 내려주는 그 직후의 모든 영역을 의미한다.
표현 영역에서 서비스 영역으로 넘어가는 그 사이에 과연 표현 영역은 어떤 값을 넘겨줘야 되는 것일까?
그냥 표현 영역에서 받은 모든 오브젝트들을 넘겨주면 안 되는 것일까?
필자의 생각과 동일하게 저자 역시 절대로 그리해서는 안된다고 말하고 있다. 위와같은 형태로 표현 레이어에서 서비스 레이어로 값을 전송해 주면 강한 커플링이 두 레이어 사이에 발생하게 되고, 추후 TC 구성이나 독립적인 단위로서의 동작에 큰 어려움이 발생하기 때문이다.
그렇다면 어떤 형태의 값을 넘겨줘야 되는 것일까?
그것은 책의 내용을 살펴보시길 권장한다.
DDD나 MVC나오브젝트 지향 개발론이나 절차 지향 개발론이나 그 모습과 형태는 아주 제각각이며 다양하다. 하지만 대부분의아키텍처 패턴 법과 개발론이 공통으로 가지고 있는 특징이 있다면 그것은 바로 추상화를 잘하라는 점이다.
즉 어떤 모듈의 동작을 커플링 도는 환경 속에 노출되지 않게 하며 최대한 독자적으로 동작할 수 있게 구성함으로써추후의 확장성과 이식성 그리고 신규 기술의 도입을 용이케 하라는 것이다.
DB와 서비스 로직을 구성하는 데에는 다양한 Lib로부터 가져온 기능과 클래스 등이 사용된다. 이것들은 언제든새로운 기술의 등장으로 변경이 필요한 요소들이다. 하지만 자신이 구축한 나만의 알고리즘은 그보다 뛰어난알고리즘이 나오지 않는 이상 쉽사리 변경될 일은 없다. (아직도c++의 sort는 quick sort를 이용하고있지 않은가?) 그렇기에 해당 알고리즘을 이용한 모듈을 최대한 독립시켜 외부 기능들과의 커플링을 제거함으로써추후 이식성을 높인다면 공인된 코드로써 많은 사람들에게 사랑받을 수 있을 것이리라 생각된다.
각 패턴의 가장 중요한 부분은 코드의 리사이클링과 코드의 독립성을 고도화함으로써 이식성과 확장을 함께 가져가는것임을 잊지 말자.