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

폭포수 모델링에서는

 도메인을 기획하고자하는 기획자, 도메인에 훤한 분석가, 그걸 개발하려는 개발자 모두 각각의 위치에서 각자의 역할에 충실했다.

 하지만, 이들은 서로만의 영역에서 사용되는 언어들을 주로 사용했고,

 이들은 공통된 언어를 사용하지 않았다.

 

따라서 공통된 언어가 없으니 공통된 공유문서 등을 작성하기도 어려웠고,

 이들이 고심하고 개선해서 만들어나가는 설계도나 개발 작품들이 고스란히 담기기 어려웠다.

 

이제는 

  모델링에 관심을 갖는 developer ,  개발에 참여하는 Modler  들이 함께 존재하며

  서로 공통된 언어를 사용하고, 공통된 용어를 사용하며

  심지어는 코드 그 자체를  같은 프로젝트에 투입되었지만, 서로 다른 위치에 존재하는 직업군끼리 이해할 수 있게 하였다.

  그렇게 지식의 공유를 활성화 시킬 수 있었다.

 

분석(이론)에만 치중되지 않은  설계(실무) 에만 치중되지 않은 코드를 개발하는것이 DDD의 목표이다.

 

 

도메인 지식이 관련없는 기술지식과 혼란되는것을 막기위해 도메인을 분리하며 Multi Layer로 분리한다.

대표적인 예로 3Layer ( Domain  UserInterface , Application ) 으로 분리된다.

 

 

여기서  Domain 영역의 모델을 표현하는데 사용되는 대표적인것을 알아보겠다.

Entity 이다.   이는 식별자(identifier) 로 식별되는 객체이다.  내부의 데이터들로 정의되는 것이 아닌, 식별자로 구분되고 식별되는것이 바로 엔티티라고 할 수 있겠다.

 

VO 이다.  Value Object라는 뜻으로  이것이 어떤것인지는 관심없고 단지 무엇인지 관심이 있다.

즉, 식별되지 않는 객체이고 , 내부의 데이터들로 정의되는것이다.