2. 정복기에 시작하기에 앞서
■ 처음 들었던 DDD에서의 Domain?
Domain이 설계의 중심?
관계형 데이터베이스에서 테이블의 각 속성이 가질 수 있는 값의 집합?
인터넷상에서 개인이 소유하고 있는 인터넷 주소?
각자 생각하는 Domain은 다 다를 것!
DDD에서의 Domain은 다르다!
14. Ubiquitous Language
도메인 모델 용어
Bounded Context 이름
기술적 디자인
패턴
DDD에서 소개하는 여러 패턴 이름
대규모 구조 용어
기술적인 용어
개발자가
이해하지
못하는 업무
관련 용어
모든 이들이
사용하지만 설계에
나타나지 않는 업무
관련 용어
(모델에 속하는 후보)
설계의 기술적 측면
19. Enitity
소프트웨어가 여러 과정을 거치는 과정에도
동일한 값을 유지하는 식별자를 지닌 유형의
객체
“Entity의 정체성에 초점을 맞추어야 한다.
의미에 따라 Entity를 분류한다면 모델이
더욱 투명해지고 구현은 견고해질 것이다.”
By Eric Evans
26. Why DDD?
DDD 발표를 준비하면서 많은 내용들의 글을 보았지만 DDD에 대한 요소들의 설명은 많이
찾아 볼 수 있었다.
하지만… 요소들의 설명들만큼 찾기 힘들었던 DDD의 존재이유….
덕분에 Eric Evans 님의 말을 이해하려고 노력함
27. Eric Evans 가 말한 Domain
하나의 도메인은 세상의 어떤것!
우리가 이해하기 위해 혼신의 힘을 다해야만 하는 가장 중요한 부분!
힘있고 유연한 소프트웨어를 만들게 해준다!
28. 내가 생각하는 DDD의 장점
3. 어느 분야나 트렌드는 변한다.
DDD로 잘 설계 되어있는 소프트웨어는 변하는 Trend에 재빠르게 진화할 수 있는
소프트웨어가 될 수 있다.
1. 복잡한 설계를 잘 나누는 데에 중점을 둔다.
2. DDD는 도메인 전문가와 소통을 중요하게 여긴다.
그래서 도메인이 무엇을 하고자 하는지에 명확해지기를 DDD가 유도한다.