# Messaging Mapper

> Convert domain objects to messages and back — no messaging concerns in your domain model.

- **Category**: Integration
- **Subcategory**: Messaging Endpoints
- **Canonical URL**: https://designpattern.fyi/patterns/messaging_mapper/

---

## Description
Clean, reusable architecture pattern.


## Use Cases
CustomerMapper.toMessage(customer) converts a Customer domain object to a CustomerUpdatedMessage with Avro serialization, setting the contentType, schemaVersion, and partitionKey headers. CustomerMapper.fromMessage(msg) does the reverse. Customer class has zero messaging code.





## Trade-offs


### Advantages

- Domain model stays pure — no messaging annotations or serialization logic

- Mappers are independently testable with simple input/output tests

- Schema evolution managed in mappers, not scattered across domain objects

- Single responsibility — mapper does one thing




### Considerations & Drawbacks

- Mappers can be tedious to write for complex domain objects

- Must be kept in sync as domain model evolves

- Field mapping bugs are easy to introduce and hard to catch without property-level tests

- Proliferates classes — one mapper per message type







---
**Reference**: [Original Source](https://www.enterpriseintegrationpatterns.com/patterns/messaging/MessagingMapper.html)