Moving from ORM models to Domain Driven Design aggregates

I'm going to make a big statement out of the gate; DDD doesn't need an ORM.
I even going to be sharper, ORM hurts DDD.

What is a domain driven design (DDD) aggregate?

An aggregate is a collection of entities and value objects that are linked together by a root aggregate.

class Order {
    public private(set) int $id;
    public private(set) Customer $customer;
    public private(set) Address $address
}

In this example the root aggregate is the Order entity. An entity is an object that is identifiable. The most common case is by using an id property.

The $customer is also an entity.

The $address is a value object. A value object is an object that contains valid data, but it is not identifiable.

Value object deep dive

The distinction between an entity and a value object is where an ORM hurts DDD.

For an ORM the Address is either an entity or fields as a part of Order.
When you are an experienced ORM user most of the times you opt for a relationship which means a new entity.

In an aggregate the identification of an value object is information that is not useful. In the example of the address, when the client wants to change the address of the order it is the root aggregate that is the identifier to change the value object.

A purist view of value objects is that they are immutable. This means changing then is creating a new object. A more pragmatic implementation is to make them mutable.

Making the distinction between an entity and a value object forces you to think harder about the data storage. And that is a good thing.
Like I mentioned before a value object can be fields as part of the Order entity. But with the json fields that are present in most (all?) database solutions this could also be one field that is part of the Order entity.
And there still going to be cases where a value object will be stored as an ORM entity.
It all depends on the application.

The way forward

When a project adopts a DDD architecture and it uses an ORM. I suggest to create a list of all queries that are executed by the ORM. And go over them one by one to see if they fit a DDD aggregate.

Try to phase out the use of the ORM, this will prevent the confusion between ORM entities and DDD entities.

It is common for a Domain Driven Design to use repositories to make the connection between the domains and the infrastructure.
The domain(s) provide the interface and the infrastructure takes care of the part of the application that has side effects.

Happy DDDing!