DDD ( Domain Driven Design ) 도메인 주도 설계

도메인 주도 설계 ( Domain Driven Design )

도메인을 기반으로 한 설계 방식이다.

1. 메인 모델의 작성

시나리오에 맞춰서 UML 등을 활용해서 로직을 표현한다. - 전체적인 도메인 모델 정의

2. 모델의 분리

전체적인 도메인 모델이 정의되면 모델을 분리한다.

분리 전 1.의 모델에는 전체적인 흐름이 서술되어 있다.

자세한 내용을 다루면 모델의 크기가 너무 커진다.

그래서 분리해서 만든다.

분리하는 기준은 DDD에서는 Boundary Context라고 부른다. - 업무의 독립단위 , 프로젝트 팀 단위로 나눈다.

모델을 나누면서 메인 모델과의 추적성도 부여해야한다.

Context Map 을 활용한다. = Context Map에서는 상위 모델의 모듈이 어떤 모델로 분류 되었는지 표현한다.

3. 하위 모델간의 공통 모듈 처리

하위 모델간의 공통적으로 사용하는 모듈이 있을 수 있다.

동시에 두 개 이상의 모델에서 사용되는 모듈은 Shared Kernal 이라고 부른다.

공통 모듈 관리는 AA가 맡는다. AA( Application Architect )

DDD에서는 두 개 이상의 모델의 의존성에 의한 오류 방지 책의 하나로 CI 를 권한다.

CI ( Continuous Integration )

도메인 주도 설계에 관한 간략한 이론은 이렇다.

다음은 예제를 통해서 살펴보자.

아래 시나리오를 한번 보겠다.

쇼핑몰에 관한 시나리오이다.

------------------------------------------------------------------------------

ex ) 사용자 1은 오늘 신발을 사려고 쇼핑몰에 접속했다.

사용자 1은 회원가입을 한다. 그리고 로그인 한다.

게시판에서 신발들을 살펴본 사용자 1은 사고 싶은 신발을 정했다.

사용자 1은 선택한 신발을 장바구니에 담는다.

사용자 1은 장바구니에 담은 신발을 주문한다.

------------------------------------------------------------------------------

시나리오를 글로 적어봤다.

이제 모델을 분리한다. 아래 5가지로 나눠봤다.

1. 회원 가입

2. 로그인

3. 신발 목록 출력

4. 신발 장바구니에 담기 

5. 주문하기 

1번 회원 가입 시나리오의 세부사항을 보자.

사용자는 회원 가입 화면에 접속한다.

가입 양식을 작성한다.

작성한 양식을 post 방식으로 보낸다. ( Post /user/ )

서버에서 사용자를 DB에 insert한다.

2번 로그인 시나리오의 세부 사항을 보자.

사용자는 로그인 화면에 접속한다.

아이디와 비밀번호를 작성한다.

작성한 id, pw를 post 방식으로 보낸다.

서버는 사용자를 찾는다. ( select )

3번 신발 목록 출력

사용자는 브라우저로 쇼핑몰에 접속요청을 보낸다.

서버는 페이징 된 신발 목록을 찾는다. ( select )

뷰에 신발 목록 데이터를 전달한다.

4번 신발 장바구니에 담기

사용자는 목록에서 신발을 선택한다.

선택한 신발을 장바구니에 추가한다.

서버에서 장바구니에 신발을 insert 한다.

5번 신발 주문하기

사용자는 장바구니에서 주문할 신발을 선택한다.

선택한 신발을 주문한다.

주문한 신발은 주문 기록에 추가된다.

서버에서 주문 기록에 신발을 insert한다.

4번 장바구니에 담는 부분과 주문하는 부분은 공통 모듈이 있을 수 있다.

장바구니 insert = 주문 기록 insert