CODEWITHSUNDEEP
design-patternsarchitecturedomain-driven-designadapter
NullReferenceException
NullReferenceException

Reputation: 21

What's the difference between Anti-Corruption Layer and Adapters?

Even thought there was a good answer here, the explanation is still a bit confusing me.

I do not see any huge differences between Anti-Corruption layer and Adapters and the only difference that I see is the difference in the definitions that Anti Corruption Layer is a kind of wrapper that allows you to isolate your domain from the corruption of someone else's domain.

But in another article, the Anti Corruption Layer is generally acting as Adapter.

Let's take an example. I have a library that allows me to query MongoDB from code, developed by the official MongoDB developers for my programming language. I also have a user domain model (let's name it User). The User has a unique UserID, which must match the ID in MongoDB. The library for MongoDB uses the primitive.ObjectID type for identifiers. Because I don't want to refer to the types for the database from the domain model, I create a separate type Identifier, which, in fact, is a regular string. Thus, in the domain model, UserID will be of type Identifier, and primitive.ObjectID itself will be converted to Identifier during mapping by conversion to a string.

Question: in this case, is Identifier an anti-corruption layer? Do you have any examples that can most accurately show me the difference between the anti-corruption layer and the adapter pattern?

I have read the following articles: 1, 2, 3 but none of them I find useful.

Upvotes: 1

Views: 1731

Answers (1)

Peter Csala
Peter Csala

Reputation: 22829

Anti Corruption Layer consists of

  • Adapter: It adapts one interface to another
  • Facade: An interface between callers and targets
  • Translator: It converts one data structure to another

data flow from Legacy to New

  1. The adapter knows how should the legacy system invoke methods on the facade
  2. The facade knows how to map legacy system's requests to new system's requests
  3. The translator knows how to convert legacy system's entities to new system's entities

data flow from New to Legacy

  1. The adapter knows how should the new system invoke methods on the facade
  2. The facade knows how to map new system's responses to legacy system's responses
  3. The translator knows how to convert new system's entities to legacy system's entities

As you can see, the flows are basically the same. You can think of the components like this:

  • Adapter maps the system X workflow to system Y
  • Facade maps individual system X methods to system Y
  • Translator maps parameters and return types from system X to system Y and vice-versa

Because these components are tend to be used together, sometimes all of these are smashed into a single component and it is usually named (badly) as an adapter. IMHO it is a better approach to have smaller, more focused components.

Upvotes: 6

Related Questions