[language-agnostic] 빈혈 도메인 모델 : 장점 / 단점

“빈혈 도메인 모델”이 안티 패턴인데 왜이를 구현하는 시스템이 그렇게 많습니까?

몇 가지 이유가 있다고 생각합니다

1. 시스템의 복잡성

구현하려는 경우 간단한 시스템 (인터넷에서 찾을 수있는 거의 모든 예제 및 샘플 코드)에서 :

주문에 제품 추가

이 기능을 주문에 넣었습니다.

public void Order.AddOrderLine(Product product)
{
    OrderLines.Add(new OrderLine(product));
}

멋지고 슈퍼 객체 지향.

이제 제품이 재고에 있는지 확인하고 그렇지 않은 경우 예외를 throw해야한다고 가정 해 보겠습니다.

주문이 재고에 의존하는 것을 원하지 않기 때문에 더 이상 주문에 넣을 수 없습니다. 이제 서비스를 시작해야합니다.

public void OrderService.AddOrderLine(Order order, Product product)
{
    if (!InventoryService.Has(product)
       throw new AddProductException

    order.AddOrderLine(product);
}

IInventoryService를 Order.AddOrderLine에 전달할 수도 있는데, 이는 또 다른 옵션이지만 여전히 Order가 InventoryService에 종속되도록합니다.

Order.AddOrderLine에는 여전히 일부 기능이 있지만 일반적으로 Order 범위로 제한되는 반면 내 경험으로는 Order 범위를 벗어난 비즈니스 로직이 훨씬 더 많습니다.

시스템이 기본 CRUD 이상이면 OrderService에서 대부분의 로직을 사용하고 Order에서는 거의 사용하지 않습니다.

2. OOP에 대한 개발자의 관점

어떤 논리가 엔티티에 적용되어야하는지에 대해 인터넷에서 열띤 토론이 많이 있습니다.

같은 것

주문. 저장

주문이 스스로를 구하는 방법을 알아야합니까? 이를위한 저장소가 있다고 가정 해 봅시다.

이제 주문이 주문 라인을 추가 할 수 있습니까? 간단한 영어를 사용하여 이해하려고하면 그다지 말이되지 않습니다. 사용자가 주문에 제품을 추가하므로 User.AddOrderLineToOrder ()를 수행해야합니까? 과잉 인 것 같습니다.

OrderService.AddOrderLine ()은 어떻습니까? 이제 말이 되네요!

OOP에 대한 나의 이해는 캡슐화를 위해 함수가 클래스의 내부 상태에 액세스해야하는 클래스에 함수를 배치한다는 것입니다. Order.OrderLines 컬렉션에 액세스해야하는 경우 Order에 Order.AddOrderLine ()을 넣습니다. 이렇게하면 클래스의 내부 상태가 노출되지 않습니다.

3. IoC 컨테이너

IoC 컨테이너를 사용하는 시스템은 일반적으로 완전히 빈혈입니다.

인터페이스가있는 서비스 / 리포지토리를 테스트 할 수 있지만 모든 인터페이스에 인터페이스를 배치하지 않는 한 도메인 개체를 (쉽게) 테스트 할 수 없기 때문입니다.

“IoC”는 현재 모든 프로그래밍 문제에 대한 해결책으로 찬사를 받고 있기 때문에 많은 사람들이 맹목적으로이를 따르고 이런 식으로 Anemic Domain Models로 끝납니다.

4. OOP는 어렵고 절차는 쉬움

나는 이것에 대해 약간의 ” 지식의 저주 “를 가지고 있지만, 나는 DTO와 서비스를 가진 신참 개발자들이 Rich Domain보다 훨씬 쉽다는 것을 발견했다.

Rich Domain을 사용하면 논리를 넣을 클래스를 알기가 더 어렵 기 때문일 수 있습니다. 새 수업은 언제 만들까요? 어떤 패턴을 사용할까요? 기타..

상태 비 저장 서비스를 사용하면 가장 가까운 이름으로 서비스를 제공 할 수 있습니다.