💡 소프트웨어의 복잡성을 다루는 지혜

도메인 주도 설계 - 에릭 에반스의 저서(블루북)
경우에 따라 DDD 기술 규칙과 패턴이 DDD 구현에 방해가 될 수 있음
중요한 것은 패턴 자체가 아닌 비즈니스 문제에 맞게 코드를 구성하고 동일한 비즈니스 용어를 사용하는 것
CRUD처럼 간단한 업무는 더 간단한 방법으로 관리할 수 있음

💡 Why DDD?

클린 아키텍처

• 존재 이유를 모르는 오류 검사 코드
• 수 많은 분기문
• 메서드를 고칠 때마다 코드 분석 + 기존 코드 동작 방식을 기획자가 알고 있었는지 확인해야 함
• 비즈니스 규칙은 자바, 자바스크립트, SQL, 운영 정책 등 곳곳에 존재함
  => 비즈니스 규칙을 한 곳에 모아야 겠다 !

엔티티는 가장 일반적이며 고수준인 규칙을 캡슐화한다.

소프트웨어의 존재 가치

• 소프트웨어의 본질은 해당 소프트웨어의 사용자를 위해 관련 문제를 해결하는 능력에 있다.
• 얼마나 빠른지, 얼마나 많은 처리가 가능한지는 나중 이야기
• 비즈니스의 이해, 관련 지식 쌓기, 본질적 복잡성과 우발적 복잡성의 구별이 매우 중요함(No Silver Bullet)

뭐가 문제야?

• 고층 빌딩에 입주 전부터 입주자들이 엘레베이터 서비스에 불만을 느낀다
• 속도를 높인다, 업무 시간을 엇갈리게 배치한다, 빌딩 내 사람 수를 제한한다 => 사용자 입장에서의 해결책
• 빌딩을 불 태우고 보험금을 받는 것이 건물주 입장에서는 더 좋은 해결책일지도...

도메인

• 소프트웨어로 해결하고자 하는 문제 영역
• 쇼핑몰 구축 -> 전자 상거래 도메인 -> 전자 상거래에 대한 이해

도메인 모델

• 모델 : 목적을 위해 현실 세계에 존재하는 것을 가공하고 편집하여 정보를 제공
• 특정 다이어그램이 아니라 다이어그램이 전달하려는 아이디어
• 목적을 가진 의사소통 수단
• 회의, 기획, 디자인, 개발 전 과정에 사용되어야 한다.
• 도메인 모델을 사용하면 여러 이해관계자가 동일한 모습으로 도메인을 이해하고 도메인 지식을 공유하는 데 도움이 된다.

💡 도메인 주도 설계

• 해결해야 하는 문제 영역이 너무 크다 => 분할 정복 하자!
• 관심사를 분리 && 격리하여 문제 해결에 집중할 범위를 정한다.
  도메인 주도 설계란 프로젝트의 모든 이해 관계자들이 일을 잘하는 방법
  MSA에서 넘어오는 사람들이 많더라...

현실

• 기획자의 도메인 모델 != 개발자의 도메인 모델
• 개발자는 요구 사항을 기술 언어로 번역
• 번역된 언어는 의사 소통을 위해 다시 번역
  => 의사 소통 비용의 낭비!

에릭 어반스의 저서

• 애자일 && 익스트림 프로그래밍의 열렬한 지지자
• 의사소통을 개선하고 프로젝트 방향을 빠르게 변경할 수 있는 능력을 향상시키자.

세 개의 기둥

유비쿼터스 언어

• 코드의 가독성을 높여서 코드를 분석하고 이해하는 시간을 절약할 것
• 용어가 정의될 때마다 용어 사전에 이를 기록하고 명확하게 정의해서 모든 사람이 공통된 언어를 사용할 수 있게 한다.

전략적 설계

전술적 설계

• repository
• aggregate
• event
• ...

Bounded Context

• 하위 도메인마다 같은 용어라도 의미가 다르고 같은 대상이라도 지칭하는 용어가 다름
• 모델은 특정한 컨텍스트 안에서 완전한 의미를 갖는다.
• 구분되는 경계를 갖는 컨텍스트를 DDD에서 Bounded Context라고 한다.
• 하나의 bounded context는 하나의 팀에만 할당해야 한다.
  => bounded context는 마이크로서비스랑 비슷하네요~

context map

• bounded context는 결국 모여서 하나의 도메인이 되니까 상호 교류하는 시스템의 목록을 제공해야 함!
• 의사 소통의 촉매

애그리거트

• 엔티티나 vo를 하나로 묶은 군집
• 상위 수준에서 도메인 모델 간 관계를 파악하기 위해
• 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다.

리포지터리

• 우리는 엔티티별로 리포지터리를 만들지만, DDD 관점에서는 애그리거트별로 리포지터리를 만드는 게 맞다. @Repository

도메인 서비스

• 애그리거트에 넣기 애매한 도메인 개념은 억지로 넣기보다 도메인 서비스를 이용해 명시적으로 드러낸다.

DDD 전제 조건

• 개발자만을 위한 것이 아니다.
• 이해관계자들의 스폰서십이 필요하다.

DDD 아키텍처

DDD만의 아키텍처는 없다. 도메인을 잘 보호하기 위한 아키텍처를 사용하면 되는 것