DDD 세미나에서 느낀 것들

[주의] 이 글은 Common Sense의 범주에 벗어난 내용들이 일부 있을 수 있음을 알립니다.
그렇게 생각한 항목에 대해선🎃이모지로 표시하겠습니다.

 

 

3월에 바쁜 일이 너무 많이 있어서 밀린 포스팅이 한 가득이지만,

우선 DDD 세미나가 가장 최근에 있었기 때문에 여운이 아직 남아있을 떄 올리는 것이 좋다고 생각했다.

 

나는 DDD를 좋아한다. 그러나 아쉽게도 좋아한 세월에 비해 이해의 정도는 낮은 것 같았다.

공유 커널과 안티 코렙션 계층 등을 이용해서 무언가를 설계해 본적은 없기 때문이다.

이건 내가 코드 레벨에서의 이해도가 낮았기 때문에 도전 조차 못했던 것으로 느껴졌다.

 

지인의 정보를 최대한 캡슐화하고자, 정보 전달에 필요한 부분만 따로 캡쳐해서 조립했다

 

그래서 그런지 평상시 좋아하는 모임에 DDD 강의가 열린다는 소식을 들었을 때는 무척 반가웠다.

 

발표한 사람은 평상시 모각코에서 몇 번 안면을 튼 적이 있는 분이셨다. 난 그의 현실적인 업무/개발 스타일에 대해 마음에 들었다. 또 노련하고 경력자스럽게, 개발에 관해 아는 것이 풍부했다. (22년까지는 경력과 엔지니어링 지식이 비례하지 않음을 보여주는 개발자들이 많았던 것 같았다...)

 

DDD 세미나에 대해서 다루는 내용과 발표자의 생각이 무척 많았던 만큼 느끼는 것도 많았다.

아래의 내용들은 다루고자 하는 뼈대의 내용은 동일하지만 조금 더 구체적인 정보와 내 생각의 살을 붙였다.

 

HW에 비해 SW의 발전 속도는 느리다

지금은 로그 함수의 곡선을 타지만 한 때는 무어의 법칙을 따라 2배 가까이 HW가 발전했다.

하지만 SW는 그렇지 못했고, 프로그램의 엔트로피가 증가하기 시작하기 시작하면 그 생산성은 줄어들기 시작했다.

그러던 중 2008년에 에릭에반스가 도메인 주도 설계 책을 내놓는다.

 

관련 역사

1995 - 자바 탄생

1997 - EJB 릴리즈

2003 - 스프링 프레임워크 릴리즈

2008 - 에릭 에반스 DDD 출간

2013 - 반 버논의 DDD Implementation 출간

2016 - 반 버논의 DDD Distilled 출간

 

제약을 두는 것 🎃

(이 부분은 누군가 의견을 내셨는데... 신비한 해석으로 보여서 여기 적어본다.)

고급 개발자들은 상대적으로 저급 개발자들을 위한 제약에 대해 설계한다.

그리고 저급 개발자들은 그 제약을 따름으로써 일정한 생산 속도를 보장한다.

SI와 같은 폭포수 모델은 이와 같은 개발 환경에서 일정 산정이 가능하고 그에 따라 가격을 산정하여 프로젝트를 수주한다.

 

모든 하위 도메인에 대해서 DDD를 적용해야 하는가

하위 도메인은 핵심, 지원, 일반으로 나뉘어진다. DDD를 하는 것 자체에 대한 설계 리소스가 있는데, 과연 일반, 지원 하위 도메인의 위치에 있는 도메인 조차 DDD 설계를 적용해야 하는가? 기준은 사람에 따라 다르겠지만 만일 자신이 맡은 업무가 자주 사용하지 않는, 혹은 몇 개월 정도 사용하다가 사라질 간단한 도메인이라면 필수는 아닐 것이라는 생각이 오고 갔다. 나 또한 핵심 도메인이 아닌 곳에서는 DDD 적용이 필수가 아니라 생각한다. (DDD가 팀 아키텍처로 잡힌 곳에서)

 

내가 생각한 DDD의 필수 적용 여부는 상황별로 아래와 같다

DDD가 팀 아키텍처로 자리 잡은 상황

핵심: 필수

일반, 지원: 선택

 

DDD가 팀 아키텍처로 자리 잡지 않은 상황

핵심, 일반, 지원: 선택

 

 

DDD와 OOP의 시초 생물학에도 결함이 있다 🎃

재미있는 생각이었다.

OOP와 Small Talk를 만든 창시자 앨런 케이는 본디 생물학을 전공한 컴퓨터 과학자라고 한다.

따라서 생물학에 대한 개념이 OOP를 만들 때 이론적 토대가 되었다는 가정이다.

그리고 생물학 자체가 개념적으로 모순을 가지고 있다고 한다

위와 같은 분류 체계는 과거와 달랐으며 현대에도 모순이 있다고 한다 (발표자 분이 약 3가지에 걸쳐서 굉장히 구체적인 예시를 들었지만 놓쳤다...)

따라서 그 생물학을 상속받은 OOP, 그리고 그것을 상속받은 DDD에도 결함을 상속받았다는 것

 

이벤트 소싱 방식의 통신

강연자 분은 금융, 핀테크에서 오래 일한 경력이 있었던 분이었다. 각 원장 테이블에는 그것에 해당하는 서브 테이블이 있었는데, 이벤트에 대한 아웃박스 테이블 겸 History 테이블이었다. 이것을 통해서 Audit(감사)처럼 어떤 날에 무슨 일이 있었는 지를 추적할 수 있으며 혹시 장애가 발생하면 부서별로 누구의 잘못이 있었던 것인지를 알 수 있다.

 

다른 얘기긴 하지만, MSA화가 되면 안 좋은 것 중 하나는, 자신의 잘못을 빠르게 회수할 수 없다는 것이 있다는 경험담이 있었다. 원장 테이블의 특정 record가 문제가 있고 관련 데이터들 모두가 자신의 부서에 있으면 회수를 할 수 있다. 하지만 MSA화가 되어 해당 데이터가 부서의 영역으로 넘어가면 관련된 모든 유관 부서에게 연락을 돌려야 한다.

"죄송합니다만, 제가 방금 처리했던 데이터가 있는데, 잘못된 방식으로 처리 되어서 롤백을 요청드리고자 하는데..."

 

후 ㅠ 눈물이 난다. 나도 20년도에는 이와 같은 유사 경험이 있었다. 차라리 야근을 해서라도 원복을 하면 다행이지만... 그렇지 않으면 부끄러운 기억이 남겨진다.

 

PK에 꼭 무의미한 ID를 매핑해야 할까?

(DDD와는 무관한 내용일 수 있지만, DB에 대한 개인적으로 정말 좋은 생각 공유였다고 느꼈다)

주민번호 등과 같은 인간 세계에 의미있는 값은 PK로써 취급하기 좋다. 그러나 훗날 개인보호 정보법이 강화되면서 모든 테이블에 해당 값을 지우게 되었고, 외래키 연관관계를 조사하여 FK를 변경하는 고통이 따랐다고 한다. (실제로 해보면 상당히 골치 아프다고 한다.)

이런 부분은 동의하지만 통계성 데이터에는 날짜와 같은 충분히 유의미한 유니크한 값이 존재한다. PK 또한 클러스트링 인덱스이다. 테이블에는 되도록 인덱스를 5개 이하로 잡으라는 말이 있을 정도로 한정된 자원이다.

또 인덱스가 있을 경우 리빌드라 해서 Command성 연산에 대해서 레드 블랙 트리 재정렬이 이루어진다. (컴퓨팅 연산 필요)

따라서 키로써 가치가 있는 날짜를 PK로 잡는 것으로 인덱스로 인한 공간/시간적 성능을 절약할 수 있다.

 

 

그 외 김영한님의 DDD에 대한 생각

내 기술 사랑은 JPA로부터 시작되었는데, 김영한님에게서 처음 배웠다.

김영한님의 JPA에 대한 생각을 알 수 있는 자료를 첨부해본다.

 

 

 

관련 링크

- 인프런: 객체들간의-연관관계-설정

- 인프런: cascade-질문

 

 

같이 읽으면 좋을 책

- 도메인 주도 설계 핵심 (2016), 반 버논

- 도메인 주도 설계 구현 (2013), 반 버논

- 도메인 주도 설계란 무엇인가?, 에이벨 아브람, 플로이드 마리네스쿠 공저

 

같이 보면 좋은 글

- 토비의 DDD 포스팅 

- 엘런 케이와 OOP, 가상의 이야기

- MicroSoft CQRS