DDD - 비즈니스 의사 결정은 데이터베이스 로직을 기반으로합니다.

Question

다음 패턴으로 DDD를 따르려고합니다. 위의 그림에서 보듯이

Controller-----DataContract----> Domain Layer (DDD) 

Controller-----Domain Object---> Repository---Entity--->EntityFramework 

는 도메인 층 비즈니스 결정을 내릴 독립적이지만, 내 경우, 비즈니스 의사 결정의 대부분은 즉시 가져옵니다. 예를 들어,

if(Account Number Associated?) 
    Load CustomerDetails //A database call is needed 
    .... 
    ..... 
    if(Has customer another loan) 
      ..... 
      ..... 
      Load other loan details //A database call is needed 
      ..... 
      ..... 
      if(Was that repaid?) 
       .... 
       .... 
       Load collateral details //A database call is needed 
       ..... 
       ..... 
       Calculate collateral details and return. 
      else 
       Load other data //A database call is needed 
     else 
      Load other data //A database call is needed 

else 
    Load other data //A database call is needed 

위의 예에서 알 수 있듯이 응용 프로그램은 데이터베이스 호출을 통해 신속하게 많은 비즈니스 결정을 내리고 있습니다. 도메인 레이어은 리포지토리 레이어에 의존해서는 안되므로 진행 방법을 모르겠습니다.

나는 데이터베이스 호출에 응용 프로그램 서비스를 사용할 수 있지만 다음 도메인 계층는 어떠한 논리가없는 것입니다. 모든 논리는 신청 서비스에 들어갑니다.

도와주세요.

-Pandian

Answer 1

한 번에 전체 집계를로드 할 저장소를 설계

1) 중 적어도 세 가지 방법이 있습니다. 이 접근법은 필요시 상태를로드하려고 시도하지 않고 도메인 모델에 즉시 필요한 모든 상태를 제공합니다.

2) 앱 서비스에서 쿼리를 실행하고 데이터를 도메인 모델에 전달합니다. 이상적으로는 (도메인 모델에 대한 단일 호출을 만들기 위해) 사전에이 작업을 수행하는 것이 좋지만, 도메인 모델에서 필요한 데이터가 무엇인지를 응용 프로그램 서비스에 알려주고 응용 프로그램 서비스에서 데이터를 반환하고 반환합니다.

3) 필요한 데이터를 읽을 수있는 저장소를 도메인 모델로 전달하십시오. 이것은 본질적으로 "도메인 서비스"패턴이지만 데이터 저장소에 액세스하는 데 사용됩니다.

이 디자인에서 도메인 모델은 저장소 인터페이스를 정의하고 있으며 응용 프로그램은 구현을 제공합니다. 즉, 서비스 제공 업체 패턴을 사용하여 종속성 화살표가 올바른 방향을 향하게합니다.

Answer 2

@Pandiarajan 도메인 계층은 도메인 모델 (엔터티, 값 개체), 도메인 서비스 및 도메인 이벤트를 포함 할 수 있습니다.

위의 코드에서 값 개체 또는 엔터티로 자연스럽게 모델링되지 않은 모든 도메인 논리 및 개념을 캡슐화하는 도메인 서비스를 만들 수 있습니다. 이러한 도메인 서비스는 모든 데이터베이스 호출을 처리하는 저장소를 사용할 수 있습니다.

반환해야하는 데이터가 읽기 전용이거나보고 목적을위한 것이라면 CQRS를 대안으로 사용할 수 있습니다. CQRS에서 이러한 모든 읽기 쿼리는 데이터를 표시 할 때 도메인 계층을 우회 할 수 있습니다. CQRS를 사용하면 데이터를 도메인 모델로 변환 할 필요가 없습니다.