The adapter layers responsibility is translating the internel representation of data to an external representation, or the other way around. This can be seen as an Ontology Matching. Therefore, this layer needs the knowledge of both the external and internal domain, and needs to be changed each time when the internal or external domain changes.
Some elements in the adapter layer are:
- Translate UI specific values into Domain objects (e.g., query string, POST data)
- Translate DB specific values into Domain objects (e.g., Data mappings, Data Transfer Objects)
Studio uses typically the following elements for the interface layer:
| Connectivity | Configuration |
|---|---|
| Service call | Data mapping |
| Schema set | |
| Domain schema |
Patterns
Mapping for external data services
HDN messages (https://www.hdn.nl/) are a data format for exchanging mortgage information in the Netherlands. It uses attributes that you might not need for your application, or want to name or structure differently. In order to keep this separate from your domain layer, you should create a separate module and use a Data mapping to transfer information from and to this different format. Your domain layer should not care about the structure in which information is send or stored in the outside world.
Anti Patterns
Blueriq as a Service (BAAS) with complex mapping
When modelling a BAAS, you have full control of the contract. This means that in the BAAS application, the contract can match the internal representation in the domain layer closely, if not entirely. Making a complex mapping at this point is overhead which is not needed.
Overview
Content Tools