Domain
도메인은 소프트웨어가 취급하는 '어떤 활동이나 관심과 관계가 있는 지식' 즉, 소프트웨어가 해결해야되는 문제이다.
소프트웨어의 복잡성이 증가하면, 도메인의 복잡성이 증가된다는 말로 직결된다.
예를 들면, 쇼핑몰 사이트를 구축한다고 했을 때 로그인을 해서 상품을 비교하고 주문을 하는 전체 과정이 도메인이 될 수 있다.
(도메인의 한 루틴안에 비지니스 로직이 포함된다.)
도메인이 어떤 소프트웨어의 기능이라고 생각할 수 있는데 꼭 그렇지는 않다. 소프트웨어 전체가 도메인이 될 수 있고 시스템 자체가 도메인이 될 수 있다.
Domain Model
- 도메인을 분석하여 모델을 구분하는 일
- 도메인 모델링
- 도메인을 개념적으로 표현
기본 요소
1) Entity
2) Value
3) Aggregate
4) Repository
5) Service
Entity
- 모델을 표현
- 고유 식별값을 가짐
- 스스로의 라이프 사이클 소유
Value
- 고유의 키값을 가지지 않음
- 데이터의 표현
- 속성의 불변성
Aggregate
- 관련된 객체의 묶음
Repository
- Entity의 저장소
Service
- Domain 객체에 위치시키기 어려운 오퍼레이션을 가지는 객체
- Service Domain의 operation은 일반적으로 Stateless 하다.
- 여러 도메인을 다룰 수도 있다.
출처 : https://www.slipp.net/wiki/pages/viewpage.action?pageId=24641881
=> 전체 큰 틀은 Repository 다. Custom, Accout 2개의 Entity가 존재하며 Custom Entity는 name, address 등 value를 갖는다.
=> 각각의 집합체(aggregate) 경계를 통해 value를 접근할 수 있으며, root의 기본 값은 entity이다.
=> 서비스는 Entity가 처리할 수 없는 비지니스 로직을 수행한다.
ex) 사용자에게 계좌정보를 메시지로 전달
Domain Driven Design
도메인 패턴을 중심에 놓고 설계하는 방식
스프링프레임워크의 모체인 Interface21의 Ramnivas Laddad가 정리한 DDD의 세 가지 특징을 살펴보자.
첫째는 도메인 그 자체와 도메인 로직에 초점을 맞춘다는 것이다. 일반적으로 많이 사용하는 데이터중심의 접근법을 탈피해서 순수한 도메인의 모델과 로직에 집중하는 것을 말한다.
둘째는 보편적인(ubiquitous) 언어의 사용이다. 도메인 전문가와 소프트웨어 개발자 간의 커뮤니케이션 문제를 없애고 상호가 이해할 수 있고 모든 문서와 코드에 이르기까지 동일한 표현과 단어로 구성된 단일화된 언어체계를 구축해나가는 과정을 말한다. 이로서 분석 작업과 설계 그리고 구현에 이르기까지 통일된 방식으로 커뮤니케이션이 가능해진다.
셋째는 소프트웨어 엔티티와 도메인 컨셉트를 가능한 가장 가까이 일치시키는 것이다. 분석모델과 설계가 다르고 그것과 코드가 다른 구조가 아니라 도메인 모델부터 코드까지 항상 함께 움직이는 구조의 모델을 지향하는 것이 DDD의 핵심원리이다.
물론 DDD는 방법론이 아니다. 따라서 이런 경우 이렇게 하라는 식의 접근법 보다는 원칙과 핵심가치를 설명해주고 그것에 어떻게 집중할 것인가에 주목하게 하는 것이다. 모든 애플리케이션의 핵심은 결국 그 애플리케이션을 사용할 도메인과 그 로직이라고 본다면 소프트웨어 설계와 구현도 그 부분이 핵심이 되는 것이 마땅하다는 것이 DDD의 개념이라고 생각하면 된다.
(http://www.zdnet.co.kr/news/news_view.asp?artice_id=00000039170214&from=Mobile)
http://domainlanguage.com/ddd/
https://www.slideshare.net/baejjae93/ss-27536729
https://www.slideshare.net/madvirus/ddd-final