I want to build an application following Domain-Driven Design (DDD).
As I understand it, DDD implies a clear separation between the domain layer and the infrastructure layer. Database models (tables, ORM models) belong to the infrastructure layer, while domain entities belong to the domain layer.

The main issue I’m struggling with is data mapping. Consider the following approaches:

1. Using ORM models as domain entities

   This approach is convenient because it avoids an extra mapping step from ORM models to domain entities. However, if domain entities are supposed to contain business behavior, those methods would need to be defined directly on the ORM models. This feels wrong, since ORM models are part of the infrastructure layer.

2. Defining explicit domain entities

   In this case, ORM models and domain entities are separate. However, this requires mapping from ORM models to domain entities. From a performance perspective, this feels suboptimal: the ORM already maps database rows to objects internally, and then an additional mapping step is required to convert those objects into domain entities.

3. Using raw SQL instead of an ORM

   With raw SQL, there is no “hidden” ORM mapping. Rows are fetched directly and manually transformed into domain entities. This seems like the cleanest approach from a DDD perspective, but it raises another concern: manual mapping. Mapping is easy for flat entities, but becomes much more complex when dealing with aggregates or nested entities. At that point, it feels like reimplementing a small ORM manually.

Which of these approaches is considered the most common and recommended in practice when applying DDD?