어디에서 CreatedDate, CreatedBy, ModifiedDate, ModifiedBy 같은 필드를 설정해야합니까? 현재 사용자 컨텍스트를 리포지토리에 전달하고 거기에 설정해야할까요, 아니면 더 좋은 방법은 응용 프로그램 서비스에 설정하는 것입니다 (하지만 리포지토리의 추가/업데이트뿐 아니라 각 API 메서드에서 수행해야합니다).DDD : 수정 날짜를 어디로 설정해야합니까? 저장소 또는 응용 프로그램 서비스?
저장소에 설정하는 것이 좋습니다. int operatorId 또는 비슷한 이름의 기존 추가/업데이트 방법에 하나의 매개 변수를 추가하십시오.
응용 프로그램 서비스에 코드를 넣으면 항상 자신을 반복해야합니다. 그리고 일부 값을 설정하는 것을 잊어 버린 경우 변경 사항이 저장 될 때 예외가 throw됩니다 (때로는 더 나 빠지고 예외는 없지만 더티 데이터).
우리는 항상 응용 프로그램 서비스 내에 엔티티 상태를 설정합니다. 리포지토리는 데이터를 저장하기위한 것이며 논리를 포함하지 않아야합니다. 도메인 엔티티는 응용 프로그램 서비스에서 작성/수정되므로이 필드를 설정하는 곳입니다. 엔티티가 데이터베이스에 저장되었을 때 생성/수정 날짜가 반영되어서는 안되며 엔티티가 실제로 저장/수정되었을 때 반영되어야합니다.
또한 우리는 일반적으로 도메인 엔티티를 데이터 계층 엔티티에 매핑하여 기본 데이터베이스 기술에보다 친숙해질 수 있어야합니다. automapper와 같은 도구를 사용하여 이러한 매핑을 자동화하는 데 도움이됩니다. 데이터 엔티티에 존재하지 않는 엔티티에 해당 항목이 있으면 불필요한 복잡성이 추가됨
"리포지토리는 데이터를 저장하기위한 것이며 논리가 포함되어서는 안됩니다."따라서 'StudentRepository'에'GetStudents (int grade) '라는 메서드가 잘못되었다고 생각됩니다. 학점별로 학생을 얻는 논리가 있기 때문에? –
bstrack은 "도메인 비즈니스 로직"을 의미한다고 가정합니다. – Khronos
도메인에 따라 다릅니다.
값이 CreatedDate, CreatedBy ... 인 경우 추적 또는 로깅 목적으로 사용하는 경우 Infrastructure (저장소)에 배치합니다.
반면에 이러한 값이 내 도메인에 속한 경우 도메인 계층에 배치합니다.
예 : 은행 송금 컨텍스트에서 고객은 결제를 위해 제출 한 후 24 시간까지만 송금을 취소 할 수 있습니다. 그런 다음 도메인은 불변량을 만족시키기 위해 CreateTransferDate을 필요로합니다.
또 다른 옵션은 모든 도메인 이벤트를 사용하고 발생한 일에 대한 기록 시간 데이터를 저장하는 수신기 일 수 있습니다.
엔테이트가 유효하지 않은 상태에있는 것을 허용하지 않습니다. 우리는 계약 확인 (사전 조건, 불변 조건 및 해당되는 경우 사후 조건)에 의한 설계 시행으로이를 수행합니다. 그런 식으로 아무도 값을 설정하지 못하게 할 수 있습니다. – bstack