[oop] DDD-엔티티가 리포지토리에 직접 액세스 할 수없는 규칙

정말 훌륭한 질문입니다. 나는 같은 발견 경로에 있으며 인터넷을 통한 대부분의 답변은 솔루션을 가져 오는 것만 큼 많은 문제를 일으키는 것으로 보입니다.

그래서 (지금부터 1 년 동안 동의하지 않는 것을 쓸 위험이 있음) 여기까지의 발견이 있습니다.

우선, 우리는 풍부한 도메인 모델을 좋아합니다. 이 모델 은 높은 검색 가능성 (집계로 수행 할 수있는 작업)과 가독성 (표현식 메소드 호출)을 제공합니다.

// Entity
public class Invoice
{
    ...
    public void SetStatus(StatusCode statusCode, DateTime dateTime) { ... }
    public void CreateCreditNote(decimal amount) { ... }
    ...
}

우리는 다음과 같은 이유로 엔티티의 생성자에 서비스를 주입하지 않고이를 달성하려고합니다.

• (새로운 서비스를 사용하는) 새로운 행동을 도입하면 생성자가 변경 될 수 있습니다. 즉, 변경은 엔티티를 인스턴스화하는 모든 행에 영향을 미칩니다 !
• 이러한 서비스는 모델의 일부가 아니지만 생성자 주입은 해당 서비스를 제안합니다.
• 서비스 (인터페이스조차도)는 종종 도메인의 일부가 아닌 구현 세부 사항입니다. 도메인 모델은 바깥 쪽을 향한 종속성을 갖습니다 .
• 이러한 의존성이 없으면 엔티티가 존재할 수없는 이유 가 혼란 스러울 수 있습니다 . (신용 메모 서비스라고합니까? 나는 신용 메모로는 아무 것도하지 않을 것입니다 …)
• 인스턴스화를 어렵게하여 테스트 하기가 어렵습니다 .
• 이 엔티티를 포함하는 다른 엔티티는 동일한 종속성을 갖기 때문에 문제가 쉽게 퍼집니다. 이는 매우 부 자연스러운 종속성 처럼 보일 수 있습니다 .

그러면 어떻게 할 수 있습니까? 지금까지의 결론은 메소드 종속성 과 이중 디스패치 가 적절한 솔루션을 제공한다는 것입니다.

public class Invoice
{
    ...

    // Simple method injection
    public void SetStatus(IInvoiceLogger logger, StatusCode statusCode, DateTime dateTime)
    { ... }

    // Double dispatch
    public void CreateCreditNote(ICreditNoteService creditNoteService, decimal amount)
    {
        creditNoteService.CreateCreditNote(this, amount);
    }

    ...
}

CreateCreditNote()이제 신용 메모 작성을 담당하는 서비스가 필요합니다. 엔티티 에서 검색 가능성 을 유지 하면서 이중 디스패치를 사용 하여 작업 을 담당 서비스로 완전히 오프로드합니다 .Invoice

SetStatus()이제 로거에 대한 간단한 종속성 이 있으며 이는 분명히 작업의 일부 를 수행 합니다 .

후자의 경우 클라이언트 코드에서 작업을 더 쉽게하기 위해 대신로 로그인 할 수 있습니다 IInvoiceService. 결국, 인보이스 로깅은 인보이스에 본질적인 것처럼 보입니다. 이러한 단일 기능 IInvoiceService은 다양한 작업을위한 모든 종류의 미니 서비스가 필요하지 않습니다. 단점은이 서비스가 정확하게하는 것이 무엇인지 모호하게한다는 것입니다 수행 . 이중 디스패치처럼 보일 수도 있지만 대부분의 작업은 실제로 SetStatus()자체적으로 수행 됩니다.

의도를 밝히기 위해 매개 변수 이름을 ‘logger’로 지정할 수 있습니다. 그래도 약간 약한 것 같습니다.

대신 IInvoiceLogger(코드 샘플에서 이미했던 것처럼) 을 요청 IInvoiceService하고 해당 인터페이스를 구현하기로 결정했습니다. 클라이언트 코드는 그 와 같이 매우 특정한 송장 고유의 ‘미니 서비스’를 요청 IInvoiceService하는 모든 Invoice메소드에 단일 코드를 사용할 수 있으며, 메소드 서명은 여전히 ​​원하는 것을 명확하게 보여줍니다.

리포지토리를 정확하게 처리하지 않은 것으로 나타났습니다. 로거는 저장소이거나 저장소를 사용하지만보다 명확한 예를 제공하겠습니다. 저장소가 한두 가지 방법으로 필요한 경우 동일한 접근 방식을 사용할 수 있습니다.

public class Invoice
{
    public IEnumerable<CreditNote> GetCreditNotes(ICreditNoteRepository repository)
    { ... }
}

실제로, 이것은 항상 문제가되는 게으른 부하에 대한 대안을 제공 합니다 .

업데이트 : 역사적인 목적으로 아래 텍스트를 남겼지 만 게으른 하중을 100 % 제거하는 것이 좋습니다.

사실, 재산 기반의 게으른로드, 난 않는 현재 생성자 주입을 사용하지만 지속성-무식한 방법이다.

public class Invoice
{
    // Lazy could use an interface (for contravariance if nothing else), but I digress
    public Lazy<IEnumerable<CreditNote>> CreditNotes { get; }

    // Give me something that will provide my credit notes
    public Invoice(Func<Invoice, IEnumerable<CreditNote>> lazyCreditNotes)
    {
        this.CreditNotes = new Lazy<IEnumerable<CreditNotes>>() => lazyCreditNotes(this));
    }
}

한편으로 Invoice데이터베이스에서 를로드하는 저장소 는 해당 신용 메모를로드하고 해당 함수를에 삽입하는 함수에 자유롭게 액세스 할 수 있습니다 Invoice.

반면에 실제 새 코드를 작성하는 코드 Invoice는 빈 목록을 리턴하는 함수 만 전달합니다.

new Invoice(inv => new List<CreditNote>() as IEnumerable<CreditNote>)

(관습 ILazy<out T>은 우리에게 추한 캐스트를 제거 할 수는 IEnumerable있지만 토론을 복잡하게 만듭니다.)

// Or just an empty IEnumerable
new Invoice(inv => IEnumerable.Empty<CreditNote>())

귀하의 의견, 선호 사항 및 개선 사항을 기꺼이 듣고 싶습니다!

답변