Why are data transfer objects (DTOs) an anti-pattern?

Question

Some projects have all data twice. Once as domain objects, and once as data transfer objects.

This duplication has a huge cost, so the architecture needs to get a huge benefit from this separation to be worth it.

DTOs are not an anti-pattern. When you're sending some data across the wire (say, to an web page in an Ajax call), you want to be sure that you conserve bandwidth by only sending data that the destination will use. Also, often it is convenient for the presentation layer to have the data in a slightly different format than a native business object.

I know this is a Java-oriented question, but in .NET languages anonymous types, serialization, and LINQ allow DTOs to be constructed on-the-fly, which reduces the setup and overhead of using them.

DTO an AntiPattern in EJB 3.0 says:

The heavy weight nature of Entity Beans in EJB specifications prior to EJB 3.0, resulted in the usage of design patterns like Data Transfer Objects (DTO). DTOs became the lightweight objects (which should have been the entity beans themselves in the first place), used for sending the data across the tiers... now EJB 3.0 spec makes the Entity bean model same as Plain old Java object (POJO). With this new POJO model, you will no longer need to create a DTO for each entity or for a set of entities... If you want to send the EJB 3.0 entities across the tier make them just implement java.io.Serialiazable

OO purists would say that DTO is anti-pattern because objects become data table representations instead of real domain objects.

I don't think DTOs are an anti-pattern per se, but there are antipatterns associated with the use of DTOs. Bill Dudney refers to DTO explosion as an example:

http://www.softwaresummit.com/2003/speakers/DudneyJ2EEAntiPatterns.pdf

There are also a number of abuses of DTOs mentioned here:

http://anirudhvyas.com/root/2008/04/19/abuses-of-dto-pattern-in-java-world/

They originated because of three tier systems (typically using EJB as technology) as a means to pass data between tiers. Most modern day Java systems based on frameworks such as Spring take a alternative simplified view using POJOs as domain objects (often annotated with JPA etc...) in a single tier... The use of DTOs here is unnecessary.

Some consider DTOs an anti-pattern due to their possible abuses. They're often used when they shouldn't be/don't need to be.

This article vaguely describes some abuses.

If you're building a distributed system, then DTOs are certainly not an anti pattern. Not everyone will develop in that sense, but if you have a (for example) Open Social app all running off JavaScript.

It will post a load of data to your API. This is then deserialized into some form of object, typically a DTO/Request object. This can then be validated to ensure the data entered is correct before being converted into a model object.

In my opinion, it's seen as an anti-pattern because it's mis-used. If you're not build a distributed system, chances are you don't need them.