1. 도메인 모델은 무엇인가?

. 비지니스 도메인에 관한 소프트웨어 모델

. 객체 모델이 아닌 비지니스와 데이터, 행동을 가진다.

. DDD를 사용하면 도메인 모델은 아주 작고 집중된 형태일 가능성이 크다.


2 내가 왜 DDD를 해야 할까?

. 도메인 전문가와 개발자들의 눈높이를 맞추자. 

  .. 비지니스 전문가: 비지니스 가치에 집중

  .. 개발자: 기술과 문제의 기술적 해결에 집중

  .. ERP는 소프트웨어에 비즈니스를 맞추는 최악의 경우가 될 수도 있다.(조직개편, 프로세스 변경 등 더 큰 비용 발생)

. 비지니스 전문가들과 지속적으로 발견하고 토론해 나가자.

. 팀원 모두가 쓸줄아는 공통 언어를 사용하여 개발하자.

. 설계는 코드이며, 코드가 설계다.


3. DDD가 해줄수 있는 일

 1. 비지니스 전문가의 심적 모델을 반영한 소프트웨어 개발

 2. 비지니스의 전략적 이니셔티브(Initiative)를 다룬다. (기술적 문제 해결)

 3. 전술적 설계 모델링 도구를 사용해 개발된다.


4. 도메인 복잡성

. 가장 중요한 핵심 도메인 - 서브 도메인 순서로 진행

. DDD로 가장 단순하게 복잡한 도메인을 모델링하라.


5. DDD는 어떻게 하는가?

DDD를 받치는 가장 큰 두 기둥

  1. 유비쿼터스 언어

  2. 바운디드 컨텍스트



* 유비쿼터스 언어 (Ubiquitous: 만연하다, 어디서나 발견되다)

- 도메인 전문가와 개발자가 공통으로 사용하는 언어

- 공통된 언어를 사용하도록 하며 실제 언어처럼 사용함에 따라 성장한다.


USE CASE

'간호사가 환자에게 정량의 독감 백신을 투여한다.'

Vaccine vaccine = vaccines.standardAdultFluDose();

nurse.administerFluVaccine(patient, vaccine);


- 각 어플리케이션의 서비스 메소드는 하나의 유스케이스 플로우를 처리하도록 하자

@Transactional

public void changeCustomerPersonalName(....)

- 언어는 계속 성장한다 refactoring 해나가면 된다.


- 바운디드 컨텍스트 당 하나의 유비쿼터스 언어가 존재한다.

- 유비쿼터스 언어는 바운디드 컨텍스트를 결리시키고, 그 안에서 개발 업무를 수행하는 팀 내부에서만 유비쿼터스하다.

- 컨텍스트 맵을 사용해 바운디드 컨텍스트를 통합한다.



6. DDD를 사용하는데서 오는 가치

1. 조직이 그 도메인에 유용한 모델을 얻는다. 

. 핵심 도메인의 초첨을 두며, 비지니스를 차별화하고 경쟁우위를 달성하는데 필요한 것을 정확히 제공할 것이다.

2. 정교하고 정확하게 비즈니스를 정의하고 이해한다.

. 유비쿼터스 언어를 통한 도메인 분석을 통한 비지니스의 가치를 전략적이고 전술적으로 분석

3. 도메인 전문가가 소프트웨어 설계에 기여한다.

4. 사용자 경험이 개선된다.

. 도메인 중심의 언어로 개발된다.

5. 순수한 모델 주변에 명확한 경계가 생긴다.

. 바운디드 컨텍스트에 노력을 집중한다.

6. 엔터프라이즈 아키텍처의 구성이 좋아진다.

. 경계가 명시적으로 나타나 관계와 통합이 왜 필요한지 이해하게 된다.

. 컨택스트 맵을 사용한다.

7. 애자일하고, 반복적이고, 지속적인 모델링이 사용된다.

8. 전략적인 동시에 전술적인 새로운 도구가 적용된다.


7. DDD 적용의 난관

. 유비쿼터스 언어를 만드는데 시간과 노력을 계산하는 것

. 도메인 전문가를 시작부터 참여시키고 프로젝트 내내 함께하는 것

. 도메인 내의 해결책에 관한 개발자의 사고 방식을 바꾸는 것





'디지털 양피지 > Domain Driven Design' 카테고리의 다른 글

3. 컨텍스트 맵  (0) 2017.12.08
2. 도메인, 서브도메인, 바운디드 컨텍스트  (0) 2017.12.01
DDD의 큰 그림  (0) 2017.11.29
Posted by 빨간 양말