Assembler vs Entity Translator and Entities vs DTO

Question

I was hoping that someone could explain the exact difference between an Assembler and Entity Translator.

Martin Fowler describes the Assembler as a sort of Mapper(?) which converts DTOs into Domain objects and vice versa.

When you're working with a remote interface, such as Remote Facade (388), each call to it is expensive. As a result you need to reduce the number of calls, and that means that you need to transfer more data with each call. One way to do this is to use lots of parameters. However, this is often awkward to program - indeed, it's often impossible with languages such as Java that return only a single value.

The solution is to create a Data Transfer Object that can hold all the data for the call. It needs to be serializable to go across the connection. Usually an assembler is used on the server side to transfer data between the DTO and any domain objects.

However, this description sounds very similar to the Entity Translator.

"Implement an entity translator that transforms message data types to business types for requests and reverses the transformation for responses.

The entity translator is an object that is tightly coupled to message data types and business entities, while providing loose coupling between the consumers of the types. In other words, components of an application use the translator to transform data types and the translator has no knowledge about operations provided by the application. This behavior provides the ability to change data types on either end of the interaction without requiring changes to the other end. The only component that needs to be updated is the translator itself"

So this is a little bit confusing.

The reason why I'm asking this question is because I'm currently building out a client library which will allow me to retrieve/send data through remote REST API; however as I map this response data into my DTOs I had considered creating an additional anti-corruption(?) layer which will then map those DTOs into my Domain Models.

Basically, I would like to distribute these libraries via composer as a prepackaged module but still have the flexibility to swap them out should I find something better.

Another question I'd like to ask is how to differentiate between Entities + DTOs since Entity is a term which is often brought up whenever I discuss Data Mappers(which is how I'm currently structuring my client libraries). Although I just referred to them as DTOs; the term "Entity" is often used to describe the type of objects you would either pass into or retrieve via the Data Mapper.

I suppose it's possible that I've been using Active Record pattern for far too long but the two of them basically just look like Anemic Domain Models me - ie: just getters and setters.

How do I properly distinguish between the two?

• Robert Harvey: It sounds like you're taking the terms "Assembler" and "Entity Translator" too literally. Those are just words that describe a concept; it's more important to understand the concept than it is to use the "right" word. I've heard them called "Mappers" as well; in fact, there's a library called Automapper that does just that. Focus on the concepts, not the terminology.
• Robert Harvey: An Entity is something in the business domain that is modelled with a software object. A DTO is just a container for some data that you want to move from one place to another; hence the name "Data Transfer Object."

Answer 1

The concepts of Mapper/Assembler/Translator are variations of the same thing. Depending on the pattern, framework or author of your reference material that you are working within the names of classes and helper libraries used may use either of these terms interchangeably.

Each of these patterns involves an intermediary service that transposes data from entities of a given type to another type specifically to decouple between different models. The mapper is implemented at the boundary of 2 domains, for instance in APIs to map between domain entities and DTOs. The mapper itself is often tightly coupled to each domain, but it allows the two domains to evolve independently, only the mapper itself needs to be updated as the schemas diverge.

While not always necessarily so, the different terms do imply that certain techniques are used in the implementation.

• When the term Mapper or Auto Mapper is used, this often indicates that there is some dynamic or convention based logic involved, that not all of the translations between types are explicitly defined. This term is frequently used in implementations that are loosely coupled or late bound.

• Assemblers are often implemented as 1-way translations and may be combined with Disassemblers that further decouple any reverse translations if any are required.

• Translators imply expected 2-way translations, so both the A->B and B->A translations would be implemented.

Another question I'd like to ask is how to differentiate between Entities + DTOs

Basically, in terms of mappers, the implied difference is which model the entity originates. With regard to DTOs (Data Transfer Objects), DTO is used to refer to the external model, no logic in the local scope will manipulate the DTOs. At the boundary the inputs are first translated to Domain Entities and after any processing or retrieval logic, the outputs are translated back to DTOs.

This can get confusing if you have multiple layers of domains that need to be mapped, it is only to simplify the concept that we reduce mappers down to talking about Entities and DTOs, really it's just two sides of a boundary between different conceptual models. If your solution has multiple domains or multiple models, you just need to be clear about the definitions of those domains when you use them. You might for instance designate individual models for Data Access (DAL), Business Logic (Domain) and DTOs.

Just be clear in your implementation what the difference is between these models, usually they will be separate namespaces, but I would suggest also using different naming conventions or prefixes or suffixes to differentiate between them.