Where should you validate the state of "other" aggregates?

Question

Scenario:

A customer places an order, then, after receiving the product, provides feedback on the order process.

Assume the following aggregate roots:

• Customer
• Order
• Feedback

Here are the business rules:

1. A customer can only provide feedback on their own order, not someone else's.

2. A customer can only provide feedback if the order has been paid for.

   class Feedback {
       public function __construct($feedbackId,
                                   Customer $customer,
                                   Order $order,
                                   $content) {
           if ($customer->customerId() != $order->customerId()) {
               // Error
           }
           if (!$order->isPaid()) {
               // Error
           }
           $this->feedbackId = $feedbackId;
           $this->customerId = $customerId;
           $this->orderId = $orderId;
           $this->content = $content;
       }
   }
   

Now, assume the business wants a new rule:

3. A customer can only provide feedback if the Supplier of the order's goods is still operating.

   class Feedback {
       public function __construct($feedbackId,
                                   Customer $customer,
                                   Order $order,
                                   Supplier $supplier,
                                   $content) {
           if ($customer->customerId() != $order->customerId()) {
               // Error
           }
           if (!$order->isPaid()) {
               // Error
           }
           // NEW RULE HERE
           if (!$supplier->isOperating()) {
               // Error
           }
           $this->feedbackId = $feedbackId;
           $this->customerId = $customerId;
           $this->orderId = $orderId;
           $this->content = $content;
       }
   }
   

---

I've placed the implementation of the first two rules within the Feedback aggregate itself. I feel comfortable doing this, especially given that the Feedback aggregate references all of the other aggregates by identity. E.g., the properties of the Feedback component indicate that it knows of the existance of the other aggregates, so I feel comfortable having it know of the read only state of these aggregates as well.

However, based on it's properties, the Feedback aggregate has no knowledge of the existance of the Supplier aggregate, so should it have knowledge of the read only state of this aggregate?

The alternative solution to implementing rule 3 is to move this logic to the appropriate CommandHandler. However, this feels like it's moving domain logic away from the "center" of my onion-based architecture.

Answer 1

If transactional correctness requires one aggregate knowing about the current state of another aggregate, then your model is wrong.

In most cases, transactional correctness is not required. Businesses tend to have tolerance around latency and stale data. This is especially true of inconsistencies that are easy to detect and easy to remedy.

So the command is going to be run by the aggregate that changes state. To perform the not necessarily correct check, it needs a not necessarily the latest copy of the state of the other aggregate.

For commands on an existing aggregate, the usual pattern is to pass a Repository to the aggregate, and the aggregate will pass its state to the repository, which provides a query that returns an immutable state/projection of the other aggregate

class Feedback {
    void downvote(Repository<Supplier.State> query) {
        Supplier.State supplier = query.getById(this->supplierId);
        boolean isOperating = state.isOperating();
        ....
    }
}

But construction patterns are weird - when you are creating the object, the caller already knows the internal state, because it is providing it. The same pattern works, it just looks pointless

class Feedback {
    __construct(SupplierId supplierId, SupplierOperatingQuery query ...) {
        Supplier.State supplier = query.getById(this->supplierId);
        boolean isOperating = state.isOperating();
        ....
    }
}

We're following the rules by keeping all the domain logic in the domain objects, but we aren't really protecting the business invariant in any useful way by doing so (because all of the same information is available to the application component). For the creation pattern, it would be just as good to write

class Feedback {
    __construct(Supplier.State supplier, ...) {
        boolean isOperating = state.isOperating();
        ....
    }
}

Answer 2

I know this is an old question, but I'd like to point out that the issue directly stems from an incorrect premise. That is, the aggregate roots we are meant to assume exist are simply incorrect.

There is only one aggregate root in the system you have described: Customer. Both an Order and Feedback, while they may be aggregates in their own right, are dependent on the Customer for existence so are not themselves aggregate roots. The logic you provide in your feedback constructor seems to indicate that an Order MUST have a customerId and Feedback MUST also be related to a Customer. This makes sense. How can an Order or Feedback not be related to a Customer? Additionally, Supplier seems to logically be related to Order (so would be inside this aggregate).

With the above in mind, all of the information you want is already available in the Customer aggregate root and it becomes clear you are enforcing your rules in the wrong place. Constructors are terrible places to enforce business rules and should be avoided at all costs. This is what it should look like (Note: I'm not going to include constructors for Customer and Order because Factories should probably be used. Also not showing all interface methods).

/*******************************\
   Interfaces, explained below 
\*******************************/

interface ICustomer
{
    public function getId() : int;
}

interface IUser extends ICustomer
{
    public function getUsername() : string;

    public function getPassword() : string;

    public function changeUsername( string $new ) : void;

    public function resetPassword( string $new ) : void;

}

interface IReviewer extends ICustomer
{
    public function provideFeedback( IOrder $order, string $content ) : void;
}

interface IBuyer extends ICustomer
{
    public function placeOrder( IOrder $order ) : void;
}

interface IOrder
{
    public function getCustomerId() : int;

    public function addFeedback( string $content ) : void;
}


interface IFeedback
{
    public function addContent( string $content ) : void;

    public function isValidContent( string $content ) : void;
}



/*******************************\
   Implentation
\*******************************/



class Customer implements IReviewer, IBuyer
{
    protected $id;

    protected $orders = [];

    public function provideFeedback( IOrder $order, string $content ) : void
    {
        if( $order->getCustomerId() !== $this->getId() )
            throw new \InvalidArgumentException('Customers can only provide feedback on their own orders');

        $order->addFeedback( $content );
    }
}


class Order implements IOrder
{
    protected $supplier;

    protected $feedbacks = [];

    public function addFeedback( string $content ) : void
    {
        if( false === $this->supplier->isOperating() )
            throw new \Exception('Feedback can only be added to orders if the supplier is still operating.');

        // could be any IFeedback
        $feedback = new Feedback( $this );

        $feedback->addContent( $content );

        $this->feedbacks[] = $feedback;
    }
}


class Feedback implements IFeedback
{
    protected $order;

    protected $content;

    public function __construct( IOrder $order )
    {    
         // we don't carry our business rules in constructors
         $this->order = $order;
    }

    public function addContent( string $content ) : void
    {
        if( false === $this->isValidContent($content) )
            throw new \Exception("Content contains offensive language.");

        $this->content = $content;
    }
}

Okay. Let's break this down a little bit. The first thing you will notice is how much more declarative this model is. Everything is an action, it becomes clear WHERE business rules should apply. The design above doesn't just "do" the right thing, it "says" the right thing.

What would lead anyone to assume rules are being executed in the following line?

// this is a BAD place for rules to execute
$feedback = new Feedback( $id, $customerId, $order, $supplier, $content);

Second, you can see that all of the logic pertaining to validating business rules is carried out as closely as possible to the models to which they pertain. In your example, the constructor (a single method) is performing multiple validations against different models. That breaks SOLID design. Where would we add a check to make sure that the Feedback content doesn't contain bad words? Another check in the constructor? What if different kinds of Feedback need different content checks? Ugly.

Third, looking at the interfaces, you can see there are natural places to extend/modify the rules through composition. For example, different kinds of orders can have different rules regarding when feedback can be provided. Order can also provide different kinds of feedback, which in turn can have different rules for validation.

You can also see a bunch of ICustomer* interfaces. These are used to compose the Customer aggregate we need here (probably not just called Customer). The reason for this is simple. It's VERY likely that a Customer is a HUGE aggregate root that spreads out all over your domain/DB. By using interfaces, we can decompose that one aggregate (which is likely too large to load) into multiple aggregate roots that only provide certain actions (like ordering or providing feedback). You can see the aggregate in my implementation can BOTH place orders AND provide feedback, but cannot be used to reset a password or change a username.

So the answer to your question is that aggregates should validate themselves. If they can't you likely have a deficient model.