Normalizer
A Normalizer detects messages arriving in diverse formats and translates each into one canonical representation so downstream components handle a single schema. It combines a content-based router with format-specific translators around a shared canonical data model.
A Normalizer converts messages that arrive in many different formats into one common, canonical format. It combines a content-based router and a set of message translators: it detects each message's format and applies the matching translator so everything downstream sees a single representation.
The problem it solves is format diversity. When a system integrates many sources — different partners, devices, or legacy applications — each may send the same logical information in its own structure. Writing every downstream component to understand every input format is unmaintainable. The normalizer concentrates that complexity in one place.
How It Works
The normalizer first identifies the format of an incoming message, typically with a content-based router examining headers or structure. It then routes the message to a translator specific to that format, which maps it onto the canonical model. All translators output the same schema, so downstream consumers are written once against that schema.
The canonical data model is the linchpin: a stable, well-designed internal representation that input formats are mapped to and, on the way out, mapped from. Adding a new source means adding one detector rule and one translator, with no change to downstream logic.
XML order --\
CSV order ---> [Normalizer] --> canonical Order --> downstream
JSON order --/
When to Use It
Use it when multiple sources send semantically equivalent data in incompatible formats, when building a hub-and-spoke integration or ESB, or when establishing a canonical data model so internal systems are insulated from external variety. It is foundational to enterprise integration and B2B onboarding.
Avoid it when there is only one input format — a single translator suffices.
Trade-offs
Normalization centralizes and isolates format complexity, dramatically simplifying downstream code and making new-source onboarding cheap. The cost is maintaining the canonical model and a growing library of translators, plus the risk that a poorly designed canonical model becomes a bottleneck or forces lossy mappings. Format detection must be reliable; misclassification corrupts data.
Related Patterns
It is composed of a Content-Based Router plus Message Translators. A Content Enricher may complete normalized messages. The Anti-Corruption Layer uses normalization to keep foreign formats out of a domain model.
Example
A logistics hub receives shipment notices as EDI, XML, and JSON from different carriers. A normalizer detects the format, translates each to a canonical ShipmentNotice, and every downstream service — tracking, billing, notifications — reads only that canonical type.