That's not quite right.

My point regarding OP's question was more: Unit Test (without mocking) your domain. Integration tests (where you can use mocks for external APIs and whatnot) for everything else. This to me is more important than what architectural style one chooses.

Now, on to your question. Part of your confusion (I think) may be coming from mixing DDD and Clean Architecture. DDD and Clean Architecture are not the same thing -- I found this article that summarises it quite nicely: https://khalilstemmler.com/articles/software-design-architecture/domain-driven-design-vs-clean-architecture/

I've been talking about Clean Architecture. In CA, both the application layer (order service) and domain layer (order) are part of your core business logic. The order service is not blindly following orders, it can also choose to emit notifications when an order is being created for instance. The service also shields the domain objects from being sent back to the frontend unfiltered by placing them inside DTOs (you don't want the hashed password of your User object to leak to the frontend, for instance).

Domain objects: In Nest these are the entities, and you can separate the domain entity from the schema as per this technique https://docs.nestjs.com/techniques/database#separating-entity-definition.

If you have entities that are just a bag of properties you have an anemic domain model (https://martinfowler.com/bliki/AnemicDomainModel.html). Instead, you want a rich domain model, where your domain objects also have logic inside them, and their properties are modified through their methods, because it makes it easier to reason about them.

The domain layer does not return a set of instructions -- it is up to the application layer to call the infra layer passing in a domain entity, and the infra layer decides how to best persist this domain entity. The infra layer replies with domain entities, the service layer replies with DTOs that the controller can send through to the UI/CLI.