Domain Driven Design?

Domain Model과 Data Model은 어떤 차이가 있나요?

다들 뭔가 알고 있는듯한데 조금씩 다른 이야기를 하는것 같습니다.

 DDD(Domain Driven Design)에 대해선 요즘에 읽고있는 "Lean software development"에서
짧게 언급하고 있기에 인용합니다.

....중략....
 Domain Driven Design 에서 에릭 에반스는 모델 주도 설계(DDD)를 두고 말하길 소프트웨어 구현 방식을
직접적으로 끌어낼수 있는 도메인 모델을 만드는 작업이라고 하였다.

 도메인 모델은 고객이나 고객 대표 그리고 실제 코드를 작성하는 개발자가 바로 사용할수 있고 이해할 수
있어야 한다. 에반스는 이런 도메인 모델이 유비쿼터스 언어라고 주장한다.

 즉, 개발자와 고객이 모두 같은 뜻을 말하기 위해 같은 언어를 사용하며 보통 이 언어는 고객이 쓰는
언어가 되어야 한다.

 이것이야 말로 양측이 의미있는 대화를 나누면서 개발자들이 자신의 문제를 잘 이해하고 있는지 고객이
검증할수 있는 유일한 방법이다.
 개발자들은 틀림없이 기술적인 인프라 문제에 관해서는 좀더 전문적인 모델을 사용하겠지만 , 모든 비지니스
규칙, 비지니스 프로세스 , 해당 도메인 관련 사안은 이렇게 고객과 개발자가 협력하여 진화시킨 도메인 모델을
통해 구현하고 검증할것이다.

 어떤것을 모델링하는 방법은 여러가지가 있다.

 협력 모델링 방식(joint modeling)은 결과가 도메인의 쟁점들을 제대로 표현하면서도 동시에 효과적으로
소프트웨어로 구현되게 한다.

 모델 주도 설계는 복잡한 시스템에 쓸만한 접근 방식이다. 모든 사람이 같은 언어로 말하게 하기 때문이다.

 모델은 시스템이 사용자에게 어떻게 보일 것인지 , 시스템이 의미 있는 개념과 규칙을 어떻게 다룰 것인지 ,
가치를 어떻게 전달할 것인지를 담는다.

 어떤 모델을 써야 알맞은 것인지는 해당 도메인과 그 도메인의 구체적인 사안들을 어떤 압축 형식으로 추상화 시켜야 가장 좋을지에 달려있다.
....중략....

 줄여서 말하면 , 도메인 모델은 구현하려는 대상 즉 비지니스를 고객에 가까운 언어로 표현한것을 말합니다.

 모델링이란 우리가 구현하려는 대상을 쉽게 다룰수 있기 위해 만든 일종의 추상화입니다.
다만 모호한 일반적인 언어가 아닌 좀더 정확하고 압축된 단어를 통해 표현됩니다.

 하지만 추상화에는 특별한 정답이 있는것이 아닙니다. 대상을 어떤 관점에서 보느냐에 따라 각기 다른
결과물을 나타내게 되지요.

 대상을 Entity-Relation으로 표현한다면 개체 관계모델링이 되는것이고 이것은 RDB로서
구현될수 있습니다. 물론 개체관계모델링도 논리적,물리적 모델로 나눠지지만 말이죠.

 고객이 직관적으로 인식하고있는 비지니스와 개발자의 입장으로서 구현하려는 비지니스와는
간극이 있기에 이것을 하나의 공통 언어로 표현하려는 것이 도메인모델링이 아닐까 합니다.

 도메인 모델링은 하나의 도메인 개체(entity)가 비지니스를 표현하기 때문에 보다 추상화되며 비지니스가
정적인 모델로서 표현됩니다.
 반면 유스케이스 모델은 해당 도메인에서의 동적인 관점 , 즉 사용성(usability)이 무엇인지 표현합니다.
이 모델은 상호작용하는 도메인 모델에 대해 Workflow라든지 경로(navigation)등의 표현으로서
구체화시켜줍니다.

 어떤 상황에서 어떤 모델을 써야할지는 먼저 어떤 모델이 있고 왜 이런 모델이 필요한지를 이해하고난
뒤에야 를 판단할수 있지 않을까 합니다.