DDD 延迟验证或始终有效的聚合根验证

Question

I'm confused about aggregate root validation on DDD. Where should i validate the children states when a child depends on another child?

For example, i have a billing context, which has the bill aggregate root. This root has a list of items, a list of taxes and a list of invoices (a bill can have one or more invoices). The sum of taxes should be lower or equal than the sum of items and the sum of invoices should be lower or equal than the sum of items - taxes. And i can't have two invoices with same date and duplicated items.

I read that exists two approaches for the aggregate root state validation, the always valid and the deferred validation:

I thought of implementing an deferred validation using:

class BillService {
    public Bill createBill(BillRequest billRequest) {
        Bill bill = new Bill();
        billRequest.getItems().forEach(item -> bill.addItem(item));
        billRequest.getTaxes().forEach(tax -> bill.addTax(tax));
        billRequest.getInvoices().forEach(invoice -> bill.addInvoice(invoice));
        if (bill.isInvoicesSumValid()) {
            throw new ...
        }

        return bill;
    }
}

class Bill {
    public void addItem(String itemId) {
        if (invoices.stream().anyMatch(i -> i.getId().equals(itemId))) {
            throw new ...
        }
        items.add(new BillItem(itemId, amount));
    }
    public void addInvoice(BigDecimal amount, LocalDate date) {
        if (invoices.stream().anyMatch(i -> i.getDate().equals(date))) {
            throw new ...
        }
        invoices.add(new BillInvoice(amount, date))
    }
}

or the always valid approach:

class Bill {
    private List<BillItem> billItems;
    private List<BillTax> billTaxes;
    private List<BillInvoices> billInvoices;
    public Bill(..., List<BillItem> billItems, List<BillTax> billTaxes, List<BillInvoices> billInvoices) {
        ... //setting many other attributes
        this.billItems = billItems;
        this.billTaxes = billTaxes;
        this.billInvoices = billInvoices;

        validateDuplicatedItem();
        validateDuplicatedDateInvoice();
        validateInvoiceSum();
    }
}

Using the deferred validation will make the aggregate root be on an invalid state, but seems easier to understand. Using the always valid approach will make the constructor giant and harder to understand.

Is there another way to solve this?

Answer 1

Both of these are technically valid, but there is a subtle difference between the two samples. In the always valid approach it is impossible to create a bill without all the proper information. In the deferred validation approach it is impossible for the BillService to create a bill with invalid info, but something else could. Your business rules should tell you which way to go.

If the many params in the Bill constructor bothers you, there's nothing stopping you from passing in the BillRequest to the Bill constructor. In fact that approach would be easier for callers to work with because you could have an IsValid method on the BillRequest which callers could use to make sure their request is valid before trying to create the bill. It's better to validate the incoming data as close to the source as possible.