[특강] 도메인주도설계의 사실과 오해 후기 - 조영호

트랙방에서 진행된 조영호님의 특강

 

우리가 아는 '객체지향의 사실과 오해' 책에서 말하는 형식의 '도메인 주도 설계의 사실과 오해'가 아니다.

 오늘의 특강 핵심 주제는 '도메인 주도 설계'가 어떻게 등장하게 되었는지에 대한 히스토리와 도메인 주도 설계와 객체 지향 프로그래밍에 대한 차이점 에 대해서 포문을 열었다.

우리가 말하는 도메인 주도 설계란? 무엇일까?

조영호님이 말씀하셨던 오해는 '대부분 우리가 말하는 도메인 주도 설계를 한다면?' 값객체, 엔티티, 팩토리, 애그리게이트 와 같은 것을 사용해야지만 도메인 주도 설계를 한다고 생각한다. 하지만 도메인 주도 설계란? 그렇지 어떤 기술적인/기법적인 것에 의존하는 것이 아니다.

그렇다면 도메인주도 설계란 무엇일까?

그림 1 도메인 주도 설계 요약

 조영호님이 장표를 사전허가 없이 첨부할 수 없어 비슷하게 만들었습니다. 도메인 주도 설계는 도메인 전문가와 개발자가 함께 팀을 이루고 지식을 탐구하여 함께 도메인 모델을 창조합니다. 이때 만들어지는 도메인 모델은 실제로 코드와 일치해야 합니다. 더불어서 모든 커뮤니케이션은 함께 정의된 유비쿼터스 언어를 활용해야 합니다.

이렇게 하는 것에 대한 목적이 무엇일까? 목적은 소프트웨어가 해결해야 하는 문제영역의 복잡성을 낮추기 위해서이다.

 이것이 도메인 주도 설계의 전부입니다. 그 외에는 기술적인 것이 치중된 것이다 라고 말합니다.

그 뒤에 조영호님이 에릭에반스의 도메인 주도 설계 책에서 나오는 목차를 통해 전체적인 이야기를 약 3시간 가량 해주셨습니다.

- 어떻게 이 책을 읽어야 하는지?
- 어느 포인트가 중요한 부분인지?
- 에릭에반스가 추천하는 '꼭' 읽어야 하는 부분 등

 간략히 말씀주셨던 부분에 대해서 이야기해보겠습니다. 장시간에 걸쳐 말씀하셨으며 저는 저만의 언어로 이해한 바를 재구성해서 전달드립니다.

도메인 주도 설계 책 목차 - 에릭에반스

각 파트에 대해서 왜 이런 내용을 에릭에반스가 이야기하려는지? 중점을 두고 말씀해주셨습니다.

파트 1 - 동작하는 도메인 모델 만들기

파트1 에서 말하고자하는 것은 도메인 주도 설계의 정수를 담고 있는데, 앞서 언급했던- 지식을 탐구하고 코드와 모델이 일치해야 하는 모델 주도 설계, 그리고 유비쿼터스 언어에 대해서 이야기합니다.

도메인 주도 설계을 설명하기 위해서는 파트 1의 내용으로 충분합니다.

파트 2 - 모델 주도 설계의 빌딩 블록

 하지만 대부분의 사람들은 파트 2가 도메인주도설계 라고 믿는 경향이 강하다고 합니다. 파트 2에서 말하는 것이 무엇일까요? 바로 레이어드 아키텍쳐/엔티티/값객체/팩토리/서비스/ 모듈와 같이 기술적인 것, 기법적인 것. 

 그렇다고 여기서 나오는 내용을 무시해야 한다는 것이 아니라, 파트 2 에서 나오는 내용은 정말 잘 이해한 사람은 모델이 코드와 일치할 수 있도록 이런 행위를 잘할 수 있도록 도와주는 강력한 조력자에 대한 내용이다. 그 중에서도 애그리게이트에 대해서만 이야기해보자.

일단 코드와 모델이 일치한다는 말은 모델 주도 설계를 한다는 것과 같다. 모델 주도 설계의 의미는 '구현 가능한 도메인 모델을 구성하는 요소들의 목록으로 각 구성 요소에는 구현과 관련된 다양한 가정이 내포되어 있어 모델과 구현에 관한 의사결정을 내리기 위해 필요한 용어를 제공하는 것입니다.' 모델 주도 설계의 빌딩 블록은 구현에 대한 가이드를 제공해서 복잡도를 낮추는 것 입니다.

그렇다면 모델주도설계에서 애그리게이트는 어떤 역할을 할까?

애그리게이트는 모델주도 설계에서 불변식을 만족시키는 객체 그룹 단위로 처리하는 것을 의미합니다. 또는 어떤 트랜잭션의 단위가 되기도 하고, 애그리게이트 단위로 Repository 를 추가하기도 합니다. 각각의 애그리게이트가 약한 결합을 가져서 최종적으로 결과적 일관성을 가질 수 있도록 합니다.

파트 3 - 더 심층적인 통찰력을 향한 리팩터링

파트 3 에서는 애자일과 도메인주도설계에 대해서 이야기합니다. 우리가 소프트웨어 개발에 있어 겪고 있는 것이 굉장히 많습니다.

- 왜 코드 전에 완벽하게 설계할 수 없을까?
- 왜 일정 추정에 실패할까?
- 요구사항은 항상 끝에 가야지만 명확해지는걸까?

속상하지만 현실은 위 문제를 절대 풀 수 없는 것이라 말합니다. 다만 위 문제를 받아들이고, 어떻게 대처하는가가 중요한 것이다. 처음에 애자일이 등장하게된 이유는 우리가 알고 있는 전통적인 개발프로세스를 부인하기 위해서 등장하게 되었다. 스크럼 이런게 아니라!

https://agilemanifesto.org/iso/ko/manifesto.html

애자일 소프트웨어 개발 선언

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다.

공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를

가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
- 애자일 소프트웨어 개발 선언

 재미있는 사실이 하나 있다면, 소프트웨어를 공학이라고 하더라도, 사실 공학이라는 것은 어떤 행위를 반복적으로 하더라도 원하는 결과가 동일하게 나와야 하는데- 우리의 소프트웨어 공학은 그렇지 않다라는 것이다. 그러므로 정답이 없다. 하지만 우리는 정답이 아닌 최선을 찾을 수 있다는 이야기이다. 애자일에서 말하고자하는 건 반복을 통해 피드백 을 받고 이것은 도움닫기의 역할을 하여 최종적으로 해결하고자 하는 문제에 근접하도록 하는 것입니다.

최종적으로 잦은 개발 반복주기에 맞게 진행되어야 합니다.

파트 3에 나오는 내용중에 리팩토링에 대해서도 이야기하고 있는 부분이 있는데, 리팩토링은 어떤 코드가 존재하는 가정하에 진행되는 것을 의미합니다.

파트 4 - 전략적 설계

마지막 파트 4는 개발과 정치가 만나는 곳이라고 합니다.

지금은 마이크로서비스가 일반적으로 널리 알려져 있지만, 이 책이 쓰여진 시점에서는 마이크로서비스가 절대 부흥되던 것이 아니다. 지금 시점에서 전략적 설계는 납득이 되지만, 이 책이 쓰여진 시점에서는 이해되기 어려운 부분이다.

처음 딱 언급하는 첫 마디는 '하나의 커다란 도메인 모델은 비현실적' 을 인정하고 있는지 묻는다. 배달의 민족의 도메인도 주문 -> 결제 -> 조리 -> 배달 이라는 과정에서 이 모든 것을 처음에는 하나의 도메인 모델에서 진행할 수 있을지 모른다. 그러나, 시스템의 규모가 커짐에 따라 하나의 커다란 도메인 모델은 비현실적이라고 말한다. 그러므로, 사용되는 컨텍스트에 따라 모델을 분리해야 한다고 말합니다.

사람들은 중복을 논하며 말도 안된다고 하지만, '눈으로 보는 중복이 중복이 아닐 수 있다' 라는 사실입니다. 컨텍스트에 따라 같은 용어라도 다른 역할을 합니다.

 또 파트 4에서 디스틸레이션이라는 챕터가 있는데, 디스틸레이션이라는 단어 자체의 의미는 어떤 것을 증류한다는 것입니다. 여기가 바로 개발과 정치가 만나는 곳인데, 실력이 뛰어난 개발자가 핵심 도메인을 담당하게 되고, 서브 도메인은 외주를 주거나 일반 개발자가 담당한다는 이야기이다.

마무리..

 이렇게 이 책에 대한 전체적인 내용을 빠르게 흟어봤다. 그것도 3시간동안 조영호님 말씀하셨는데, 대단하다고 느껴졌다. '도메인 주도 설계' 라는 말이 나오면 가장 먼저 떠오르는 사람은 조영호님이다. 어떻게 이렇게 이야기할 수 있지? 책을 읽었지만 소화했다고 말하기는 힘들 것 같다.

마지막으로 일부 몇가지 나의 개인적인 소견을 남겨보려 한다.

 사실 도메인주도설계 라는 것은 하지 않아도 된다. 해야 하는 이유에 대해서 100가지 이상을 찾을 수 있겠지만, 그 중에 실무에 실질적으로 도움을 준다. 라고 증명할 수 있는 것은 단 하나도 없다. 즉 해도 그만 안해도 그만. 그럼에도 불구하고 도메인주도설계를 하는 이유는 무엇일까? 

 주관적인 의견으로는 소프트웨어는 오늘 작성한 코드가 내일 또 달라질 수 있다. 또 같은 요구사항이라도 오늘과 내일의 코드가 다르다. 그런 관점에서 코드는 어떻게든 짤 수 있다. 그럼 어떻게든 짤 수 있는 코드는 과연 효율적일까? 당장은 동작하는 코드가 되었으니 문제가 없을 수 있다. 하지만 변화되는 요구사항에 우리가 대응하기 위해서는 코드에 대한 이해보다 변화되는 요구사항에 몸의 리듬을 맡겨야 한다. 여기서 말하는 몸의 리듬은 눈으로 보는 것/듣는 것/말하는 것/만져보는 것 등이 요구사항에 집중해야 된다는 것이다. 그렇게 해야만 오늘의 코드와 내일의 코드가 동일할 것이다. 그 뿐만 아니라 서비스에서 요구되는 요구사항보다 개발자가 더 앞서있을 수 있게 된다. 엄청나게 몰아치는 소용돌이 속에서도 앞서 있는 개발자는 중심을 명확히 붙잡고 나아갈 수 있을 것이다.

그렇다면  당장 실행해야 하는 것은 무엇일까?

- 코드보다 추상화된 도형이나 텍스트로 쉽게 설명하기
- 도메인 전문가는 좀 더 도메인에 대해서 많이 아는 모든 사람이다. 그러니까 더 많이 소통하기
- 팀에 좀 더 자주 도메인 용어에 대해서 이야기하기