대부분의 개발자는 데이터베이스, 클래스 기반으로 설계하는 경향이 있습니다.

데이터베이스 주도 설계

도메인 주도 설계에서는 데이터베이스 스키마가 아니라 도메인이 설계를 주도하도록 합니다.

현실세계에는 DB라는 개념이 없는 경우도 많습니다.

무엇보다 도메인 전문가들이 DB에 대해서 알아야 할까요?

데이터베이스라는 개념은 확실히 유비쿼터스 언어의 일부가 아닙니다. 사용자는 데이터가 지속되는 방식에 신경 쓰지 않습니다.

DDD 용어로 이것을 지속성 무지(persistence ignorance)라고 합니다. 데이터베이스의 데이터 표현에 대해 걱정하지 않고 도메인을 정확하게 모델링하는 데 집중해야 하기 때문에 중요한 원칙입니다.

또한 데이터베이스 관점에서 디자인한다면, 당신은 종종 데이터베이스 모델에 맞게 디자인을 왜곡하게 됩니다.

예를들어 Order랑 필드가 거의 완전히 동일하지만, 배송까지 가지 않는 Quote(견적) 업무가 있다고 가정합시다.

해당 견적 업무를 Order 테이블에 플래그 혹은 코드로 표현하는게 적절할까요? (코드, 플래그로 유효성 검사)

비즈니스 규칙과 유효성 검사 규칙은 다릅니다.

예를 들어 주문에는 청구서 수신 주소가 있어야 하지만 견적에는 그렇지 않다는 것을 나중에 알게 될 수 있습니다.

또한 주문과 견적을 외래키로 모델링하기 어렵습니다.

추가로 해당 비즈니스 개념이 DB에서 명시적으로 보이지 않기 때문에, 유비쿼터스 모델로 사용할 수 없습니다.

클래스 주도 설계

클래스가 디자인을 주도하도록 하는 것은 데이터베이스가 디자인을 주도하도록 하는 것만큼 위험할 수 있습니다.

도메인 이해 단계에서 주문과 견적을 분리했지만 , 해당 모델에서 실제 세계에는 존재하지 않는 인공 기본 클래스인 OrderBase를 도입했습니다.

이것은 도메인의 왜곡입니다. 도메인 전문가에게 OrderBase가 무엇인지 물어보십시오!

여기서 교훈은 요구 사항을 수집하는 동안 마음을 열어야 하며 도메인에 우리 자신의 기술적 아이디어를 부과해서는 안 된다는 것입니다.