[도메인 주도 설계의 사실과 오해 5기] 1일차 내용 정리

조영호 님의 <도메인 주도 설계의 사실과 오해 5기> 오프라인 강의를 참여하면서 정리한 내용입니다. 조영호 님께서 강의해 주신 내용들을 제 입맛에 맞게 각색했기에 조영호 님께서 온전히 말씀해 주신 내용들과는 차이가 있음을 분명히 말씀드립니다. 내용에 오해 없으시길 바라겠습니다.

 

1일 차 강의는 에릭 에반스(Eric Evans)의 <도메인 주도 설계>의 파트 1,2,3,4를 어떤 식으로 이해하면 좋을 지에 대한 가이드를 주시는 방식으로 진행됐습니다.

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

1. DDD는 엄청 큰 개념이다. 패러다임들에 DDD를 묻히는 것
   1. 확실한 건 DDD와 객체지향은 같지 않다.
2. 도메인
   1. 범위를 잘라내는 것
3. 모델
   1. 수준을 잘라내는 것
   2. 커뮤니케이션을 하기 위해 사전지식을 맞추는 용도
   3. 단순화 시키는 것. 서로 이해가 가능한 정도까지
4. 모델 주도 설계
   1. 도메인 모델 -> 설계 -> 구현 의 단방향이 아니라 구현에서 뭔가가 바뀌면 설계도 바뀌고 도메인 모델도 바뀔 수 있음
   2. 즉 도메인 모델 = 코드
5. 모든 설계의 목표는 유지보수!
   1. 변경을 잘 수용하는 것
      1. 이런 관점에서 DDD의 특장점은 수정할 수 있는 포인트 즉, 도메인 모델 설계와 구현간의 간극을 확 줄여줌
      2. 용어를 일치함에 따라 머릿속에 떠오르는 그 구조가 실제 구현 구조와 매우 유사해짐
6. DDD는 사고방식이기때문에 어느 패러다임이건 베이스로 깔지 않는다.
   1. 그러나 객체지향과 애자일을 기반으로 DDD가 나오긴 했다.
7. 객체지향은 구조상 GUI와 더 잘 맞다. 서버가 오히려 안 맞는 부분이 많다.
   1. 스몰톡 같은언어들이 다 UI를 구현하기 위해 만들어진 언어들
   2. 웹이 나오기 이전에 GUI는 서버라는 개념이 잘 없었음
8. 웹의 등장
   1. 초기 브라우저의 성능이 안좋아서 비즈니스 로직들에 대한 구현체들을 전부 서버로 내려 처리하기 시작함
   2. EJB
      1. 내 로컬 객체가 다른 PC의 객체와 통신을 할 수 있게 하고 싶어(기술에 집착했던 시기, 구현이 매우 힘들었음)
      2. 특히 영속화 데이터를 다루기 위해서는 EJB에서 제공하는 인터페이스를 강제로 구현해야하는 침투적인 아키텍쳐가 너무 심했음
      3. 구현에 맞는 구조를 갖추고 기술을 끼워맞추는 게 아니라 기술에 구조를 끼워맞추길 강제하는 구조가 되었었음(침투적인 아키텍쳐아키텍처) => DDD의 탄생일화 중 하나
      4. 위 침투적인 아키텍쳐의 가장 큰 문제는 ‘관심사의 분리’가 안되는 것(비즈니스 로직과 영속화 로직이 한 곳에 묶여서 관심사 분리가 안되는 그런 예).
   3. 이런 상황에서 기술적으로 나온건 Spring, Hibernate, JPA 등등이고 DDD 역시 이때 나옴
   4. 결국, DDD는 패러다임들에 종속적이지 않지만, 객체지향 커뮤니티에서 작은 문제를 해결하던 객체지향이 큰 문제를 해결하려는 열망을 갖기 시작하면서 여러 문제들에 봉착하다가 EJB도 만들게 되고 그 끝에 DDD에 까지 도달하게 됨

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

1. DDD는 패턴 랭귀지다!
   1. DDD는 방법론/아키텍처/프레임워크가 아니다.
2. DDD의 유일한 제약
   1. 도메인 로직만 잘 격리해! 그 외엔 하고 싶은 대로 해
3. DDD를 할 때 레이어 아키텍처를 무조건 써야한다는 게 아니라 그저 예시 중 하나. 도메인 로직만 잘 격리하면 어느 아키텍쳐를 쓰던 상관없어. 오해하지 말 것
4. Validation 체크는 결국 불변식 체크
   1. 불변식 예: 삼각형의 내각의 모든 합은 무조건 180도여야 한다
5. 애그리게이트 = 불변식 = 트랜잭션단위
6. 도메인 모델 패턴 != 도메인 모델
   1. 도메인 레이어를 객체지향으로 구현한 것이 도메인 모델패턴
   2. 도메인 레이어를 간혹 절차지향으로 구현하게 된다면 트랜잭션 스크립트 패턴

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

1. 애자일의 핵심 = 변경이 나쁜게 아니야
2. 애자일의 핵심 = 리팩터링
3. DDD는 기본적으로 애자일을 깔고있다
   1. 개발은 반복주기를 통해 진행되어야 함
   2. 가장 큰 실수: 도메인을 처음부터 완벽하게 만들려는 것
4. 애자일의 핵심 = 퀄리티는 유지하되 기간을 맞출려면 기능을 줄이자
   1. 항상 릴리즈 가능한 상태로는 만들어 놔야해
5. DDD의 핵심 = 점진적으로 진행해야한다

파트 4. 전략적 설계

1. 개발과 정치가 만나는 곳
2. 핵심! 시스템에서 도메인 모델은 여러개다. 하나가 아니다.
   1. 코드를 나누세요
3. DDD의 전제는 복잡한 도메인
4. 결합도보다는 중복이 나은 경우가 훨 많다.
   1. 의도된 중복은 옳다
   2. 컨텍스트에 맞게 찢어서 가져가자
5. 하나의 커다란 도메인 모델은 비현실적이다
6. 바운디드 컨텍스트
   1. 컨텍스트에 맞게 도메인을 찢자
   2. 이곳의 티켓과 저곳의 티켓은 다르다
   3. 버티컬하게 자른다
   4. MSA는 대부분 바운디드 컨텍스트를 따른다
   5. 보통 팀 단위로 나눌 때 이렇게 많이 나눈다
7. 전략적 디스틸레이션 = 우선순위를 정하고 거기에 리소스를 부어
   1. 코어 도메인
      1. 이 회사의 경쟁적 우위를 가져갈 수 있는 도메인

 

에릭 에반스가 <도메인 주도 설계>를 세상밖으로 내면서 가장 중요시 여겼던 파트는 3과 4였다고 한다. 허나 대부분의 사람들은 방법론적으로 파트 2를 주로 찾는다.

 

위에서 다룬 내용처럼 DDD는 정말 거대하다. 그렇기에 DDD에 대해 얘기를 나누고자 할 땐 상대방이 말하고자 하는 DDD가 파트 1,2,3,4 중 어느 부분에 대한 얘기인지를 파악할 필요가 있다.