Creating and validating nested entities

[hymair]

You run the validate method from the constructor of the Entity class. (link).

In my case I have some additional getters which are not part of the EntityProps and are available only on the built instance of Entity. This means I have to validate after instantiating. Is this a good approach? I am using a zod schema to run the validation. The same goes for any nested entities inside the Aggregate. For example here I am also mapping the lines to create those entities as well (which will validate them in a similar way on create).

export class InvoiceEntity extends AggregateRoot<InvoiceProps> {
    static create(props: InvoiceProps): InvoiceEntity {
        const id = randomUUID()
        const invoice = new InvoiceEntity({
            id,
            props: {
                ...props,
                lines: props.lines.map(LineItemEntity.create),
            },
        })

        invoice.validate()

        return invoice
    }

    public validate(): void {
        invoiceSchema.parse(this)
    }

    get invoiceNumber() {
        return this.props.invoiceNumber
    }

    // ... more getters
}

[Sairyss]

You can validate in any place in the entity where it's needed. Any method can validate.
Though, for typical sanity validation (like string/number validation with Zod), I would do it only on the edge of the application where it receives external data (like input DTOs in the controller, or if you query data from external APIs). Invalid data shouldn't go any further from outer layers and shouldn't get to the domain.
In the domain we usually consider that data is already validated by the upper layers, and only validate in some rare cases where we need extra safety, or we only validate business rules (invariants), not the input sanity.
Though, if you absolutely want this extra safety, it's fine to validate inputs also in the domain, but you will need to maintain validation logic in multiple places and execute validation twice (once in outer layer, once in the domain), so I generally don't recommend this in most cases.

[hymair]

Thank you for the quick reply!

The input is validated in the controller via DTOs as well. IMO, validating input in the domain as well will help if someone removes/breaks the DTO layer validation.

Regarding nested entities inside the AggregateRoot (e.g. lines) -- is this how we are supposed to instantiate all child entities of an aggregate?

[Sairyss]

is this how we are supposed to instantiate all child entities of an aggregate?

You can instantiate directly in the props like in your example, works fine if you just need to construct an object without doing anything else. Though if you need to execute some logic, for example check invariant that involves all line items, you can create a method that updates line items and use that method instead. Method is also nice to have if you need to reuse it in other places, so you don't have to repeat code for setting line items.

[hymair]

I was planning on validating all these business rules (invariants) inside the validate method of the Invoice aggregate. Of course splitting them into their own separate methods.

In a domain such as finance and in the case of invoices, where we have non-trivial amount of validation, wouldn't the aggregate become a big god file?

[Sairyss]

In a domain such as finance and in the case of invoices, where we have non-trivial amount of validation, wouldn't the aggregate become a big god file?

If your business logic is complex, your aggregates can grow sure. But if you split you aggregates properly into entities and value objects (and also split your modules correctly) it shouldn't be too bad. Aggregate itself is just an orchestrator that calls its sub-entities and value objects and only has code for shared validation logic, not individual validation of each sub-entity.

[hymair]

Considering the ValueObject's validate method is also run inside their constructor, should they be instantiated in Aggregate.create(), the same way as nested entities (e.g. lines)?

[Sairyss]

They should be instantiated anywhere where you need them. In the create method, or in an update method, etc. Here is an example for updating user address

domain-driven-hexagon/src/modules/user/domain/user.entity.ts

Lines 77 to 93 in 43ae414

	updateAddress(props: UpdateUserAddressProps): void {
	const newAddress = new Address({
	...this.props.address,
	...props,
	} as AddressProps);
	this.props.address = newAddress;
	this.addEvent(
	new UserAddressUpdatedDomainEvent({
	aggregateId: this.id,
	country: newAddress.country,
	street: newAddress.street,
	postalCode: newAddress.postalCode,
	}),
	);
	}

[hymair]

I wanted to clarify another aspect to getters in Entities. As mentioned in previous comments, the Invoice aggregate has some calculated values like totals which are getters. They are vital part of the entity/aggregate. The problem is that they are not exposed in the getProps or toObject helper methods since they only work with this.props (while these are getters outside of props).

My initial thought is to extend/override the base getProps method in the entity and add all the getters manually to the returned object like so:

const result = {
  id: this._id,
  createdAt: this._createdAt,
  updatedAt: this._updatedAt,
  ...this.props,
  total: this.total,
  someOtherGetter: this.someOtherGetter,
  // etc.
};
return Object.freeze(result);

What is your suggestion on this?

[Sairyss]

If you absolutely need those values in the props, you can either override the method adding properties that you need, or calculate everything you need on object creation and save it in props, for example. Whatever makes more sense in your case.