Entity

..

개발자는 도메인보다 데이터에 초점을 맞추려는 경향이 있다. 
소프트웨어 개발에 관한 대부분의 접근법이 데이터베이스에 중점을 두기 때문에, 
DDD를 처음 접하 는 사람에게 일어날 수 있는 현상이다. 

풍부한 행동(Operation)을 바탕으로 도메인 개념을 설계 design 하진 않고, 
주로 데이터의 속성(열)과 연결(외래 키)을 먼저 생각하려 한다. 
이렇게 해서 데이터 모델을 대응하는 객체로 투영하게 되는데, 
이로 인해 ‘도메인 모델’ 안에 있는 거의 모든 개념이
게터와 세터 메소드를 너무 많이 갖고 있는 엔터티로 코딩된다. 

우리를 위해 이런 요소를 생성해주는 도구는 손쉽게 찾을 수 있다. 
속성 접근자 가 잘못된 건 아니지만, 
이것이 DDD 엔터티가 수행해야 하는 행동의 전부는 아니다.

엔터티가 모델링 도구로 적합하지 않을 때도 있다.
잘못된 사용은 많은 사람들이 느끼는 것보다도 훨씬 더 자주 일어난다.
대부분 개념은 값으로 모델링해야 한다.
만약 이에 동의할 수 없다면, DDD는 여러분의 비즈니스 요구에 맞지 않을 수 있으며 ,
CRUD 기반의 시스템이 더 적합할 가능성 이 상당히 높다.
이는 여러분의 프로젝 트에 드는 시간과 돈을 모두 절약할 수 있게 해준다.
문제는 CRUD 기반의 대안이 항상 여러분의 소중한 자원을 절약하게 해주진 않는다는 점이다.
비즈니스 관계자는 보통 근사한 데이터베이스 테이블 편집기를 개발하는 데만 너무 많은 노력을 들인다.

 - Implementing Domain-Driven Design 도메인 주도 설계 구현, 반 버논 p243~244

 

..