오랜 기간 읽기를 미뤄두었던 책을 다시 읽고, 그에 대한 생각을 짤막하게 남깁니다.

편하게 작성하려고 하오니 혹여 본 글을 읽으러 오신 분들께 어체에 대해서 너그럽게 봐주시길 미리 양해 부탁드립니다.

그리고 아래 내용엔 지극히 주관적인 내용이 포함되어 있음을 미리 알립니다.

대상 독자

이 책의 도입부에서는 대상 독자를 초중급이라고 소개하고 있다.

동시에, 이 책은 도메인 주도 개발(이하 DDD) 입문자를 대상으로 하며 고수가 되는 법을 알려주는 책은 아니라고 말한다.

필자 또한 크게 기대하지 않았으며, 무엇이든 내가 몰랐던 새로운 정보와 지식을 습득하기를 기대하고 읽었기에 문제되지 않았다.

그럼에도 혹여 이 책에 관심이 있는 누군가를 위해, 어느정도 개발 경험이 쌓여있는 상태에서 이 책을 읽어야 이해하는 게 수월할 것임을 미리 밝힌다.

이건 팩트다.

이미 DDD에 대해 좀 더 심층적이고 깊은 지식을 위해 준비해 둔 책이 있고, 그를 통해 한층 더 깊이 있게 DDD를 이해할 수 있을 것이라 기대한다.

그런 의미에서 개인적으로 DDD 입문서, 즉 교두보로써의 역할을 하기에 이 책은 충분했다고 생각한다.

이 책은...

DDD라는 큰 타이틀을 갖고 있지만 읽어본 결과 오로지 DDD에 국한된 것이 아닌 전반적인 시스템 설계 및 개발에 대해 다루고 있는 느낌을 받았다.

굳이 따져서 분류를 해보자면...

1. DDD 이전에 시스템 설계를 하면서 필요한, 혹은 알아야 하는 것들(DIP...) 30%
2. Domain Model(with. JPA), Repository(with. JPA), Service 등 실제 구현 30%
3. DDD를 이루는 개념(엔티티, 밸류, 애그리거트, 도메인 모델 경계-바운디드 컨텍스트, ...) 30%
4. 위 내용을 구현할 때 사용할 수 있는 Spring Boot의 일부 기능 10%

정도의 비율을 가진 구성이랄까?(이렇게 나눠놓긴 했지만 어째서인지 비율이 모호하게 느껴지는 건 대체 왜일까..)

아무래도 책을 쓰는데 선택된 기술 스택(Java + Spring Boot + JPA)이 존재하다보니 어느정도는 이 기술 스택에 의존적인 내용이 있을 수 밖에 없는 것 같긴 하다.

JPA 파트 중 일부(밸류 컬렉션, @SubSelect, @SecondaryTable, ...)를 제외하고는 거의 다 알고 있고, 실제로 사용중인 기술 혹은 구현이었기에 이해하기 어렵지도 않았다.

그리고 개인적으로 필자의 경우엔 2번, JPA를 활용한 실제 구현이 어떻게 되는지트가 가장 궁금했었는데 이부분 역시 어느정도 궁금증이 해소되어 만족스러웠다.

생각보다 구현 자체는 그리 복잡하지 않은 것 같고(물론 이 책만 보고서 느낀 것이니 실제와는 다를 수 있다), 역시 실제로 개념을 구체화하고 경계를 잘 나누는 것이 가장 중요한 듯했다.

그래서 개념에 대해서는 훨씬 더 심도있게 다룬 책들이 있는 걸로 알고 있어서, 그 책들을 통해 좀 더 다져볼 요량이다.

마지막으로, 그게 무엇이 되었든 개념을 체화하려면 충분한 경험이 필요한 법이므로, 이는 시간과 노력을 들여 현재 하고 있는 업무에 적용해가며 익혀갈 생각이다.

여하튼.

DDD가 뭔지 감이 잘 잡히지 않거나, 혹은 아예 갈피조차 잡지 못하는 독자라면 이 책을 추천한다. 그게 아니면 그냥 필자처럼 실제 눈으로 볼 수 있는 단편적인 구현이 궁금한 경우에도 이 책을 추천한다.

물론 그것만으로 모든 안개가 말끔히 걷히는 수준까지는 아니다. 그렇지만 짙은 안개 속에서 아예 보이지 않던 무언가의 형체가 흐릿하게나마 보이기 시작할 정도는 될 것이다.

반대로 DDD에 대해 어느 정도 느낌적인 느낌(?)도 있고, 그럭저럭 뭔가 해볼 수 있을 것 같다는 독자에게 추천하기는 다소 애매한 듯하다.

정말이지 대상 독자에 딱 알맞게 쓰여진 책인 것 같다.

그리고 이 모든 의견은 필자의 몹시 주관적인 것임을 밝힌다.

생각해보기

아래 내용은 모두 필자의 주관적인 생각들을 정리한 것이다.

단순히 책에 대해서만 궁금해 본 글을 읽는 독자라면 아래의 내용은 읽지 않아도 무방하다.

도메인이란 뭘까?

개발을 하다보면 심심찮게 들려오는 단어, 도메인.

그게 뭐길래 이렇게까지, 여기저기 온갖 곳에서 다루고 있는 걸까?

이 이유에 대해, 난 이렇게 추측한다.

우리는 서로 같은 언어를 구사하지만 서로 다른 뜻을 가진 세상에 살고 있다.

그러니까.. 같은 단어를 놓고도 서로 생각하는 것이 다르기 때문에 이렇게 많은 사람들의 입방아에 오르내리는 게 아닌가 싶다.

이를 달리 말하면, 도메인이라는 녀석은 명확하게 정의 내릴 수 없는 무언가, 그러니까 굉장히, 아주 추상적인, 어떠한 개념에 가까운 것이 아닐까?

필자는 수학자가 아니다. 그렇지만 이를 수식으로 표현한다면 조금 보기 편해질 것 같다.

도메인 = 개념

자, 그리고 이 정의에 따라 도메인이란 단어를 치환하면 도메인 주도 개발은 개념 주도 개발이 된다.

실제로 책의 초반부에서도 '도메인 모델은 특정 도메인을 개념적으로 표현한 것이다'라고 언급하는데, 여기서 '개념'이라는 단어가 등장한다.

개념?

자, 그렇다면 개념이란 뭘까.

나무위키에서는 아래와 같이 장황하게 설명하고 있다.

구체적인 사회적 사실들에서 귀납하여 일반화한 추상적인 관념.
...
'개념' 이라는 말 자체도 이미 하나의 개념이다. 사람이 생각해 무엇인가를 무엇으로 지정한 것이기 때문에 철저히 인위적이다.
사람이 없어도 돌은 존재하지만, 단단한 회색 덩어리를 돌이라고 인식하고 지정해서 돌이라 부르는 것은 사람이 만든 개념이다.
무엇보다 이는 보이지 않는 대상, 이를테면 사람의 생각 그 자체나 시간이나 신 같은 초월적인 무엇인가에도 적용된다. 초월이라는 것조차 하나의 개념이다.

사실 이 장황한 설명을 본다고 해도 무언가 크게 와닫는 것이 있지는 않다.

그럼에도 불구하고 필자가 이 내용을 인용한 이유는...

그러면 대체 DDD는 뭘까?

그래서 넌 그것에 대해 어떻게 생각하는데?

그렇다. 이건 필자가 DDD에 대해 이해한대로 (정말 쉽게) 풀어서 이야기 해본 것이다.

그러니까... DDD란 우리가 생각하는 어떠한 개념을 구체화하는 방식이 아닐까?

그래서 넌 그것에 대해 어떻게 생각하는데?

자, 앞선 문장의 일부 단어를 아래와 같이 바꿔서 다시 보자.

'그것'은 '대상의 기능'으로, '생각'은 정의로 말이다.

이제 위 문장은 아래와 같이 읽을 수 있다.

그래서 넌 '대상'에 대해 어떻게 '정의'하는데?

나의 짧은 식견으로 생각해봤을 땐 이 문장이 DDD의 핵심인 것 같다.

결국 가장 중요한 건 우리가 관심을 갖는 사물, 혹은 관념적인 무언가(이하 개념)에 대해 어떻게 정의를 내리고 있느냐는 것이다.

다만 이러한 개념은 그렇지 않을 수도 있지만(과연 그런 개념이 세상에 존재할까?) 대부분 또 다른 개념과 연관되어 있기 마련이고,

이러한 개념들을 한데 묶어 시스템을 만들어 내는 방식 중에 하나가 바로 DDD인 것이다.

그리고 개념이란 그 자체로 순수한 것이기에, 실제 구현 또한 개념 즉 도메인의 순수성을 지키기 위한 방향으로 이루어진다.

예를 들면...

• 도메인 영역에는 지극히 순수한, 그 어떤 외부와의 의존도 갖지 않는 코드만 존재한다든지.
• 그래서 도메인 영역에는 순수한 인터페이스를 두고, 실제 외부와의 의존을 갖는 구현체는 인프라 영역에 둔다든지.
• 이렇게 DIP를 적용하기 위해서 만들어진 인터페이스와 실제 구현체를 고수준 모듈과 저수준 모듈이라고 부른다든지.
  • 참고로, DIP를 적용할 때 하위 기능을 추상화한 인터페이스는 고수준 모듈 관점에서 도출하고 고수준 모듈에 위치한다.
  • 추가로, 아키텍처 수준에서 DIP를 적용하면 인프라스트럭처 영역이 응용 영역과 도메인 영역에 의존하는 구조가 된다.

이런 것들? (그림 2.9는 책에 오탈자가 있어서 사진을 수정했다)

물론 우리는 인간이기에 타협이라는 선택지와 손을 잡곤 한다. 어쩌면 이 책의 저자께서도...

마지막으로..

개인적으로 느끼길 이 DDD라는 개발 방식은 앞서 말한 개념의 '순수성'을 지키는 것을 매우 중요한 가치로 매기고 있는 것 같다.

추가로, 앞선 글에서 필자는 DDD가 개념을 다루어 시스템을 만들어 내는 방식이라고 했다.

그래서 개인적으로 생각하길, ORM과 함께 '잘' 사용한다면 아주 강력해질 수 있는 설계 방식이지 않을까 싶다.

ORM을 사용하는 이유 중에 하나가 OOP(객체 지향 프로그래밍)의 장점을 그대로 활용하기 위해서인데, 이 과정에서 자연스럽게 따라오는 OOP의 큰 특징 중에 하나인 추상화는 앞서 말한 개념이라는 단어와 아주 잘 어울린다고 생각하기 때문이다.

그래서 이 책의 저자인 최범균 님께서도 책의 내용을 작성할 때 사용한 기술 스택으로 JPA를 선정한 것이 아닐까?