Since K2, the Kladde has been reading tenders from TED, the EU's platform for public procurement. Back then it was a client with a few
records. Since then the Kladde has acquired a domain model in which a tender is called Tender, and modules that rely on that model. TED has a
model of its own: fields with hyphens, texts in 24 languages, deadlines per lot, types of notices that have nothing to do with
tenders. In this lesson TED gets a translator at the boundary, and you fix a bug that happens at some point in almost every
integration: A client follows a redirect and takes the sign-in page for success.
The anti-corruption layer
In the context map (4.2.5) you drew TED as an upstream context that the Kladde cannot influence, and you gave the reason why an anti-corruption layer (ACL) stands there. It has one job: The other system's model stays outside. In concrete terms:
- TED's types are
internalin the adapter. No other project can see them, and no domain type gets a field likedeadline-receipt-tender-date-lot. - The port speaks the Kladde's language. The application asks
ITenderSourcefor tenders for a CPV code and getsTenderback. Only the registration knows that TED stands behind it. - The translation has one place. One class translates a notice into a tender or says why it cannot. All decisions about the foreign model live there: which language, which deadline, which notice counts as a tender at all.
- Foreign data is not trusted blindly. Required fields are checked, lengths are limited, links are only taken over if they point where they are supposed to point. What goes into a query to TED, the Kladde checks itself.
Is that worth it for one interface? Microsoft's pattern itself asks the question: An ACL is additional code and one more place that has to be maintained. It pays off when the foreign model thinks differently from yours or changes without any action on your part. Both are true of TED. If TED changes a field, one class in the Kladde changes, and a test with a stored response tells you which one.