How to get rid of Mappers and make objects build themselves?

I am having a really hard time deciding where to instantiate my entities in the refactoring I am making.

It may be useful to review Parnas 1971; Information Hiding is a useful principle to keep in mind when you are trying to limit the amount of damage that can be done by design uncertainty.

The general guidance that we want to minimize the amount of branching in our "constructors" still holds; which is to say that

new Foo(x,y,z)

should "just" be assigning data members of Foo, or passing information to Foo's base class/classes so that those constructors can perform assignments. So if you need to do something more complicated than that (instantiating other objects, parsing raw information into useful data structures, branching), then you will typically want some variation of "Factory" or "Factory method".

See Chapter 6 of Domain Driven Design: Tackling Complexity at the Heart of Software for the original discussion of the factory pattern within the context of Domain Driven Design.

For where the code lives in your project: Factories that operate on information expressed using general purpose data types and introduce no new dependencies in your library can be part of the domain model itself. In the easiest cases, the factory is "just" a named constructor that accepts integers, strings, arrays, domain types as arguments and returns an entity (or perhaps some general purpose "sum type" that can hold an entity).

When you are dealing with something more complex (the information is in a DTO), then the factory will normally live somewhere that has visibility of the DTO and also the domain models factories.

For where the code is called in your data flow: the common answer is to push that code as close to the boundary as you can without forcing introducing unhealthy compromises. The basic idea here is that most of the program should be able to pretend that the information has been in its most useful form all along, and only a few specialized elements need to be concerned with the truth (and associated error handling, for those cases where reality doesn't quite align with the needs of the system).

Useful reading:

• Alexis King: Parse, Don't Validate
• Einar Høst: On the Complexity of JSON Serialization
• Gary Bernhardt: Boundaries

Summary: after 10+ years of looking into this, I've reached the conclusion that nobody has a great answer - it's trade-offs all the way down, and the best that you can hope for is to find an internally consistent set of trade offs that you don't regret forever.

My goal is to eliminate the Adapters and Presenters and make the DTOs build themselves (within the constructor) and the Entities will also build themeselves. I just don't know exactly where I'll call new Entity(arg1, arg2, arg3, ...).

This is a bit of a frame challenge but I think you might be pursuing valuable goals but creating unnecessary challenges for yourself by limiting your toolbox to a constructor.

That is, if you wish to move all the logic around the creation of objects to the their classes, I think there's something to that. You can do that, however, without putting that logic into the constructor. I'm use Java as the scope here because I am familiar with it and because of the evolution of the language, I think this comes up a lot in Java solutions.

But first, let's think about what a constructor actually is for a moment. It's a function which can take inputs and produce an object. So in a real sense, it's a special kind of static method with extra capabilities and restrictions. One of the main restriction is that it has to return a newly created object (or fail.) You don't even get an option to return anything else, it's just implicit. This restriction means that constructors are defacto factory methods.

The main special capability in a constructor that is relevant here is the ability to set final variables in the resulting object. This is a really useful tool for creating immutable objects (IMO) which should be the way most objects are designed. Mutability should only be used when it supports a specific purpose. But this power also creates some limitations. You only get one shot at the assignment. This isn't normally an issue, but the upshot is that your constructor code is subject to more stringent rules than normal functions.

These rules are good because they ensure that any object created is valid but when assembling a complex object, they often make things more complicated than code outside of the constructor.

There's a simple answer to this: make your constructor simple and private. By simple I mean it does no more than assign parameters to members. No conditions, no logic. Just assignments. Then you can create one or more factory methods on the class. These factory methods can do all sorts of complex logic and call the simple constructor once the input parameters are determined. You can also support post creation logic such as modifying private members, wrapping the object, add references to collections for tracking, adding observers, etc. And you can do this without exposing the internals of the object to any other class. It's all managed in the same class definition as the constructor. Moving code from the constructor to a factory method a minor change to the structure of the class but the way it allows for simpler and more correct code can be dramatic.

There seems to be a mindset that "DTO" is sacrosanct, clouding the OP's impulse to apply Single Responsibility principle due to conflating DDD framework and business domain model. Make a proper object of data AND function/behavior. Of course a proper domain object is still that if it has a method returning a DTO - a generic, non business/domain utility thing.

Thus the domain object is decoupled from any specific respository and the DDD framework more generally, making other refactoring goals possible.