06. 애그리거트를 팩토리로 사용하기.md

정리

애그리거트가 가지고 있는 데이터를 이용해 다른 애그리거트를 생성해야 한다면 해당 애그리거트를 팩토리로 사용하는 것을 고려해야 한다.

논리적으로 하나의 도메인 기능으로 구성되어 있다면 이는 통일된 과정을 통해 이루어져야 한다.

public class RegisterProductService {
  public ProductId registerNewProduct(NewProductRequest req) {
    Store account = accountRepository.findStoreById(req.getStoredId());
    checkNull(account);
    if(account.isBlocked()) { throw new StoreBlockedException(); }
    ...
  }
}

응용 서비스에서 상태 검사와 생성을 하는 것이 아닌 다음과 같이 중요한 도메인 로직을 애그리거트에서 구현하는 것이다.

public class Store {
  public Product createProduct(ProductId newProductId, ...생략) {
    if(account.isBlocked()) { throw new StoreBlockedException(); }
    return new Product(newProductId, getId(), ...생략);
  }
}

Product 생성 가능 여부를 확인하는 도메인 로직을 변경해도 도메인 영역의 Store만 변경하면 되고 응용 서비스는 영향을 받지 않는다.

도메인의 응집도가 높아지는 것이 애그리거트를 팩토리로 사용할 때 얻을 수 있는 장점이다.

애그리거트가 가지고 있는 데이터를 이용해 다른 애그리거트를 생성해야 한다면 애그리거트에 팩토리 메서드를 구현하는 것을 고려해야 한다.

Store의 데이터를 이용해 Product를 생성하고 Product를 생성할 수 있는 조건을 판단할 때 Store의 상태를 이용한다.

Store에 팩토리 메서드를 추가하면 Product를 생성할 때 필요한 데이터의 일부를 직접 제공하면서 중요한 도메인 로직을 함께 구현할 수 있게 된다.

물론 Product 애그리거트를 생성할 때 이외의 정보를 추가로 알아야 한다면 별도의 팩토리에 위임하는 방법도 존재한다.

느낀점

이 절을 읽으면서 구현 방식에 대해 많은 생각이 들었다.

저자는 Store의 데이터와 상태를 이용해 Product를 생성하기 때문에 Store 애그리거트에서 팩토리 메서드를 제공하고 있다고 말한다.

이 주장에 따르면 생성하는 주체의 데이터와 상태를 이용해 또 다른 애그리거트의 객체를 생성한다면 해당 도메인 로직은 생성하는 주체에 위치해야 한다는 건가?

애그리거트 내부에서 다른 애그리거트를 생성하는 것은 애그리거트 간의 결합도를 높인다고 생각이 된다.

오히려 Product 객체를 생성하는 것이기 때문에 팩토리 메서드를 Product 애그리거트에서 제공하고 Store의 정보를 넘기는 것이 좋지 않을까?

또는 많은 정보를 이용해야 한다면 별도의 팩토리에 위임해 Product 내부에서 호출하는 것이 좋지 않을까라는 생각이 든다.

이러한 상황은 꽤 빈번하게 일어날 것이라고 생각한다.

조금 더 고민이 필요한 내용이다...