대충 이해한 DDD

Jump to bottom Edit New page

Sanghyuk Jung edited this page Oct 20, 2017 · 3 revisions

대충 이해한 DDD

하려는 이야기

DDD를 둘러싼 분위기가 어떻게 변했다고 느끼는가?
DDD에서 무엇을 얻을 수 있다고 생각하는가?
DDD를 적용하려다보면 무엇이 걱정이 되는가?

1. DDD를 둘러싼 분위기가 어떻게 변했다고 느끼는가?

DDD가 처음 화제가 되었을 때

한 10년전?

Rich Domain이 논의의 중심
- Active Record + Domain Logic
- Spring의 @Configurable, Spring ROO
어떻게 해야할지 모르겠다.
- 좋은 사상 같은데, 구체적인 예제가 없어
의구심
- 과연 실용적인가? 과연 Java에 어울리는가?
실무에서는 Model객체에 조금씩 로직을 담는 정도로만 적용해 봄

근래

DDD에 올리는 스펙, 구현기술이 이전보다는 성숙
- JPA, Spring Data JPA
발전된 논의
- CQRS, EventSourcing
- Micrososervice와의 접목
좋은 책들이 많이 나왔다.
- 최범균님 책도..

2. DDD에서 무엇을 얻을 수 있다고 생각하는가?

결국은 늘 하는 고민

패키지를 나누기
- 경계의 기준 : 업무영역 * 레이어
- 이름
- 의존 관계, 양방향 여부
객체의 책임, 의존관계
- 객체 그래프를 어디에서 끊을 것인가?
컴퍼넌트/패키지별 담당 조직 배분
테스트하기 쉬운 구조

DDD가 주는 힌트

구체적 패턴
- presentation, application, infrastructure
  - 아키텍처 패턴?
- Aggregate Root
- 이론/개념적으로 더 정제되어 가는 느낌 : 테스트로 치면 XUnit test pattern과 비슷?
더 쪼갠 역할
- Model객체 -> DTO, Command(Form), Entity
- Entity 내부에서의 그룹핑(Embbeded)
ORM의 활용의 길잡이
결국은 객체 중심지향의 기본

구현 중 생각이 달라진 부분

업무 어플리케이션에서 Immutable한 Busineess 객체
- 너무 많은 생성자를 가진 DTO 때문에 전에는 Java에서는 실용적이지 않다고 생각했다.
- 다시 돌아보니 Model 설계를 쪼개야한다는 신호가 아닐까?
- DB 테이블의 컬럼이 많아도 @Embbeded등을 이용해서 쪼개야하지 않을까?

3. DDD를 적용하려다보면 무엇이 걱정이 되는가?

고민

이름짓기
영어
Account vs User
- 늘 했어야하는 고민

비난의 우려

데이터를 담는 객체가 너무 많아지지 않을까?
- Entity, DTO, Command, Event
Map 선호자들까지 설득할수 있을까?
Java웹개발 문화에 대한 비난을 더 크게 하지 않을까?
- 너무 만들어야할 코드가 많다? : 주로 얇은 레이어를 선호하는 문화를 가진 곳에서 나오는 비난들
Event를 통한 전파
- 적정인 Rerefence로 코드를 추적하기 어려워지지 않을까?

어떻게 극복해야할까?

응용/변형/타협