Rich vs. Anemic 도메인 모델에 대한 토론에서 인터넷은 철학적 조언으로 가득하지만 권위있는 예는 부족합니다. 이 질문의 목적은 적절한 도메인 기반 디자인 모델의 결정적인 지침과 구체적인 예를 찾는 것입니다. (이상적으로 C #에서)
실제 예에서이 DDD 구현은 잘못된 것 같습니다.
아래의 WorkItem 도메인 모델은 Entity Framework에서 코드 우선 데이터베이스에 사용하는 속성 모음 일뿐입니다. 파울러 당, 그것은 빈혈 입니다.
WorkItemService 계층은 도메인 서비스에 대한 일반적인 오해입니다. WorkItem에 대한 모든 동작 / 비즈니스 로직을 포함합니다. Yemelyanov와 다른 사람들에게 그것은 절차 적 입니다. (6 페이지)
아래 내용이 잘못된 경우 어떻게해야합니까?
동작, 즉 AddStatusUpdate 또는 Checkout 은 WorkItem 클래스에 속해야합니까?
WorkItem 모델에는 어떤 종속성이 있어야합니까?
public class WorkItemService : IWorkItemService {
private IUnitOfWorkFactory _unitOfWorkFactory;
//using Unity for dependency injection
public WorkItemService(IUnitOfWorkFactory unitOfWorkFactory) {
_unitOfWorkFactory = unitOfWorkFactory;
}
public void AddStatusUpdate(int workItemId, int statusId) {
using (var unitOfWork = _unitOfWorkFactory.GetUnitOfWork<IWorkItemUnitOfWork>()) {
var workItemRepo = unitOfWork.WorkItemRepository;
var workItemStatusRepo = unitOfWork.WorkItemStatusRepository;
var workItem = workItemRepo.Read(wi => wi.Id == workItemId).FirstOrDefault();
if (workItem == null)
throw new ArgumentException(string.Format(@"The provided WorkItem Id '{0}' is not recognized", workItemId), "workItemId");
var status = workItemStatusRepo.Read(s => s.Id == statusId).FirstOrDefault();
if (status == null)
throw new ArgumentException(string.Format(@"The provided Status Id '{0}' is not recognized", statusId), "statusId");
workItem.StatusHistory.Add(status);
workItemRepo.Update(workItem);
unitOfWork.Save();
}
}
}(이 예제는 더 읽기 쉽도록 단순화되었습니다. 코드는 혼란 스러울 수 있기 때문에 여전히 복잡합니다. 그러나 도메인 동작은 다음과 같습니다. 새로운 상태를 아카이브 기록에 추가하여 상태 업데이트. 궁극적으로 다른 답변에 동의합니다. CRUD로 처리 할 수 있습니다.)
최신 정보
@AlexeyZimarev가 Jimmy Bogard의 C # 주제에 대한 완벽한 비디오 인 최고의 답변을 주었지만 링크를 넘어 충분한 정보를 제공하지 못했기 때문에 아래의 주석으로 이동 한 것 같습니다. 아래 답변에서 비디오를 요약하는 메모에 대한 초안이 있습니다. 수정 사항에 대한 답변에 자유롭게 의견을 보내주십시오. 비디오는 한 시간이지만 시청할 가치가 있습니다.
업데이트-2 년 후
DDD의 초기 성숙도의 징후라고 생각합니다. 2 년 동안 공부 한 후에도 "올바른 방법"을 알고 있다고 약속 할 수는 없습니다. 유비쿼터스 언어, 종합적인 뿌리 및 행동 중심 디자인에 대한 접근 방식은 DDD가 업계에 기여하는 중요한 요소입니다. 지속 무지와 이벤트 소싱은 혼란을 야기하며, 이와 같은 철학은 더 넓은 채택에서 벗어나는 것으로 생각합니다. 그러나 내가 배운 내용 으로이 코드를 다시 수행해야한다면 다음과 같이 보일 것입니다.
유효한 도메인 모델에 대한 모범 사례 코드를 제공하는이 (매우 활발한) 게시물에 대한 답변을 여전히 환영합니다.
"I don't want to duplicate all my entities into DTOs simply because I don't need it and it violates DRY, and I also don't want my client application to take a dependency on EntityFramework.dll"집니다. 엔티티 프레임 워크 전문 용어 "엔티티" "도메인 모델"에서와 같이 "엔티티"와 동일하지 않습니다