IDDD 1장. DDD를 시작하며
설계는 단순히 어떻게 보이고 느껴지는가에 관한 것이 아니다. 설계는 어떻게 동장하는가에 관한 것이다.
- 스티브 잡스
DDD는 우리가 높은 품질의 소프트웨어 모델을 설계할 수 있도록 해준다.
DDD는 전략적인 동시에 전술적(DDD-Lite)인 모델링 도구
나도 DDD를 할 수 있을까?
학습 곡선이 있다!!
DDD의 가장 중심에 있는 원리
- 토의, 경청, 이해, 발견, 비즈니스의 가치
- 모든 지식을 중앙화하는 모든 것
DDD는 객체지향적 방법으로 엔터프라이즈 애플리케이션을 해결하는 방법
DDD는 MSA를 지향한다. Monolithic은 지양한다.
시니어 개발자 : 이 조직은 내가 생각했던 것보다 파괴적 진보에 관심이 없더군요. 뭐 상관 없어요 나는 포기하지 않겠어요.
도메인 전문가 : 유비쿼터스 용어로 소통하자
내가 왜 DDD를 해야할까?
개발자 <- 유비쿼터스 언어 -> 도메인 전문가
설계는 코드이며, 코드가 설계다. 설계는 어떻게 작동하는가다. - Uncle Bob도 비슷한 말을 함
옳은 소프트웨어 개발 접근 방식에 투자한다는 생각
DDD가 해줄 수 있는 일
- 도메인 전문가와 개발자는 가까운 거리에서 유비쿼터스 언어로 소통하면서 협업해야 한다.
- 기술보다는 도메인 가치가 우선이다.
도메인의 복잡성과 씨름하기
핵심 도메인과 서브 도메인
ex) 커머스 솔루션에서 핵심 도메인은 결제이며, 서브 도메인은 배송이다.
DDD를 통해서 복잡화하지 말고 단순화하라
Anemic Domain Model : 빈약한 도메인 모델. 속성만 표현하는 단순한 데이타 홀더. 보통 트랜잭션 스크립트와 연결된다. Rich Domain Model : 풍부한 도메인 모델. DDD를 통해서 도메인을 표현한 풍부한 행위를 가지는 모델
과거에는 객체 관계형 임피던스 부조화 때문에 Anemic Domain Model을 많이 사용하게 되는데, 이제 ORM이 대중화 되어서 할만하다!!
왜 무기력(Anemic)증이 일어나는가?
- 절차적 사고방식의 익숙함
- 단순한 샘플코드를 참고
- 비주얼 베이직 탓 : 클릭하고 드래그 앤 드랍 하면 프로그램이 만들어짐 - 이건 좀 ….
Getter, Setter의 자바빈을 숨기는 여러 방법이 있었지만, 대부분 개발자는 그러려고 하지 않았거나, 왜 그렇게 해야 하는지 이해조차 하지 못했다. 온통 무기력증이다.
일반적인 행위로 모든 상황(도메인 지식)을 커버하려 한다. 이것은 안티 도메인 모델이 된다. 코드로 말하면 Setter들의 향연이 벌어진다. 그저 데이터 홀더일 뿐이다. -> 무기력증
뷰를 위한 모델은 Getter, Setter로 구성되는 것이 좋다.(DTO 패턴) 하지만 도메인 모델은 아니다.
p.67 p.69 코드를 보면서 반성하자.
DDD는 어떻게 하는가?
유비쿼터스 언어 : 반운디드 컨텍스트 내에서 공유된 언어. 도메인 전문가화 개발자 모두에 의해 개발되어 공유된 언어. - 서로 많이 이야기 하자.
ex) 간호사가 독감 백신을 표준 용량으로 환자에게 투여한다. : nurse.administerFluVaccine(patient, vaccine);
- 도메인 모델링 - 소프트웨어는 계속 진화한다. 모델 설계를 관리하지 말고 언제나 버릴 수 있어야 한다. 결국 코드가 설계이다.
- 유비쿼터스 언어 용어집 만들기
- 도메인 정제 (결국 많은 이야기를 해야한다)
p.75 샘플로 도메인적 표현을 가지는 모델링을 생각해보자
- 가독성이 좋아졌다.
- 도메인의 표현이 보인다.
- 그리고 클라이언트 입장에서 테스트
DDD를 사용하는 데서 오는 비즈니스 가치
부제 : 여러분의 상사에게 DDD를 파는 방법
- 조직이 그 도메인에 유용한 모델을 얻는다.
- 정교하게 정확하게 비즈니스를 정의하고 이해한다.
- 도메인 전문가가 소프트웨어에 설계에 기여한다.
- 사용자 경험이 개선된다.
- 순수한 모델 주변에 명확한 경계가 생긴다.
- 엔터프라이즈 아키텍처의 구성이 좋아진다.
- 애자일하고, 반복적이고 지속적인 모델링이 사용된다.
- 전략적인 동시에 전술적인 새로운 도구가 적용된다.
DDD 적용의 난관
- 유비쿼터스 언어 만들기
- 도메인 전문가와 소통
- 개발자의 사고방식 전환 : 기술 보다는 도메인이 먼저다.
- 객체는 속성(데이터)이 중요한 것이 아니라 행동이 중요하다.
가장 중요한 것은 팀 내 문화와 DDD의 학습곡선 인 것 같다.
p.83을 보면 도메인 전문가와 친해지는 법이 나오는 게 진정 이런게 TIP 이다.
Example 백로그를 스프린트로 커밋한다.
Anemic Domain Model
backlogItem.setSprintId(sprintId);
backlogItem.setStatus(BacklogItemStatusType.COMMITED);
- 행위가 원자적이지 않으며, 데이터 의존적이며, 불변식이 깨질 수도 있다.
Rich Domain Model
backlogItem.commitTo(sprint);
- 도메인의 표현이 드러나고 원자적이며, 행동이 캡슐화 되어 있으며, 도메인 모델 밖으로 로직이 세어 나가지 않는다.
위 상태에서 아래와 같은 추가사항이 생길 시 어떤 방식이 더 기민하게 반응할 수 있을까?
만약 백로그 항목이 이미 다른 스프린트로 커밋됐다면, 먼저 언커밋 해야한다. 커밋이 완료되면 이해 당사자에 알려라(도메인 이벤트)
도메인 모델의 합리화
어짜피 대부분의 엔터프라이즈 웹애플리케이션에서는 도메인 모델이 좋은 선택이라고 본다.
DDD는 무겁지 않다.
with TDD. 클라이언트 입장에서 도메인 모델을 구현하는 것은 큰 도움이 된다.
가상 + 약간의 현실
협업툴!!
가상의 프로로젝트를 진행하는 것으로 이야기를 풀어보자
사스오베이션, 그들의 제품과 DDD의 사용
- 콜랍오베이션 : SNS
- 프로젝트오베이션 : ITS
DDD-Lite(전술)를 이용함. 즉 바운디드 컨텍스트(전략)는 무시함.
마무리
- 복잡성 극복
- 트랜잭션 스크립트의 단점
- Rich Domain Model이 좋다.
- DDD 약팔이
