A colleague of mine is against using DTOs and rather feels we should just return Entity / Domain objects serialized for a REST api. He feels DTO is an anti pattern and sited this article [Data Transfer Object is a Shame](http://www.yegor256.com/2016/07/06/data-transfer-object.html). Although the article sited has a different approach to solving the "DTO Problem" as my colleague is proposing. Personally I've always preferred to use DTO for three reasons.

1. My API is not tied to my domain layer, so I have flexibility. Domain layer can change without impacting the API, and vise versa.
2. When using ORMs like JPA/Hibernate I don't accidentally issue tons of queries to build the object graph to serialize, or have to put logic / annotations in my entity layer to control serialization, which is really a view concern not a domain concern.
3. I can easily control what and how much information goes over the wire, IE send the handful of fields the client wants rather than 30 fields.

Point 2 is not a big deal if an ORM is not being used. I can still see can issue though if you had something like the following

```
class Order {

    private Long orderId;

    // additional fields go here

    private List<LineItem> lineItems;
}

class LineItem {

    private Long id;
    private BigDecimal amount;
    private int qty;
}

```

Lets say the client only wanted a list of orders and didn't care about the line items. If there wasn't a DTO involved you could populate the Order object and leave the lineItems as an empty List but that would be awkward and confusing to populate it in some cases, and not others. Or all the data could be loaded and transferred but that seems wasteful and potential performance impact. 

Is there every an appropriate time to skip DTOs and just return the domain object? Or am I thinking wrong and DTO is not a pattern that should be used. Is there another approach?