Modelling aggregate root or domain service? - oop

Question

I want to model a wishlisting feature for my domain.
My invariants are:
You can't add product that is already in your wishlist
You can't add product that you own.
The second invariant made me wonder - should I model this feature as reconstituted Aggregate (outside of ORM because of $ownedProductIds that be fetched from UserProductRepository):
final class User extends EventSourcedAggregateRoot
{
// ...
/**
* #param UserId $userId
* #param ObjectCollection $ownedProductIds
* #param ObjectCollection $wishlistedProductIds
* #return $this
*/
public static function reconstituteFrom(
UserId $userId,
ObjectCollection $ownedProductIds,
ObjectCollection $wishlistedProductIds
)
{
$user = new User();
$user->userId = $userId;
$user->ownedProductIds = $ownedProductIds;
$user->wishlistedProductIds = $wishlistedProductIds;
return $user;
}
/**
* #param Product $product
* #throws ProductAlreadyPurchased Thrown when trying to add already bought product
* #throws ProductAlreadyWishlisted Thrown when trying to add already wishlisted product
*/
public function addProductToWishlist(Product $product)
{
$productId = $product->getId();
if ($this->ownedProductIds->contains($productId)) {
throw new ProductAlreadyPurchased($this->userId, $productId);
}
if ($this->wishlistedProductIds->contains($productId)) {
throw new ProductAlreadyWishlisted($this->userId, $productId);
}
$this->apply(new ProductWishlisted($this->userId, $product));
}
// ...
}
or rather create a stateless domain service:
final class Wishlist
{
public function addProductToWishlist(Product $product, UserId $userId)
{
$ownedProductids = $this->userProductRepository->findProductsOfUser($userId);
$wishlistedProductsIds = $this->userWishlistProductIdRepository->findProductsOfUser($userId);
// business rules as in User class
}
}

Answer 1

As User has all the information needed to enforce the invariants, I would leave it there. I typically only create Domain Services when some operation doesn't seem to belong in one entity (TransferMoney() method not fitting in Account class is the poster child for this).
Note though that your model is currently really simplistic. As it is, it may make sense to name the aggregate User, but in a real situation chances are you will make breakthroughs that completely change it.