At the moment, we have to build an application which is based on a legacy one. Code for that old application should be thrown away and rewritten, but as it usually goes - instead of rewriting it, we need to base something new on it. Recently, we decided to go the DomainDrivenDesign path. So -- anti corruption layer could be a solution for our problems. As far as I understand, this way it should be possible to gradually rewrite the old application.
But -- I can't find any good example. I would appreciate ANY information.
DDD defines an anti-corruption layer is an adapter pattern that isolates one part of a system, known in DDD as a bounded context, from another bounded context. Its job is to ensure that the semantics in one bounded concept do not “corrupt” the other bounded concept's semantics.
Where to draw the boundaries is the key task when designing and defining a microservice. DDD patterns help you understand the complexity in the domain. For the domain model for each Bounded Context, you identify and define the entities, value objects, and aggregates that model your domain.
Implement a façade or adapter layer between different subsystems that don't share the same semantics. This layer translates requests that one subsystem makes to the other subsystem.
Domain-driven design (DDD) is a software development philosophy centered around the domain, or sphere of knowledge, of those that use it. The approach enables the development of software that is focused on the complex requirements of those that need it and doesn't waste effort on anything unneeded.
From the DDD book (Domain-Driven Design: Tackling Complexity in the Heart of Software) by Eric Evans:
The public interface of the ANTICORRUPTION LAYER usually appears as a set of SERVICES, although occasionally it can take the form of an ENTITY.
and a bit later
One way of organizing the design of the ANTICORRUPTION LAYER is as a combination of FACADES, ADAPTERS (both from Gamma et al. 1995), and translators, along with the communication and transport mechanisms usually needed to talk between systems.
So, you might find examples by looking at the suggested adapter pattern and facade pattern.
I'll try to paraphrase what Eric Evans said, your anti-corruption layer will appear as services to the outside of your layer. So outside of the anti-corruption layer the other layers will not know they are "speaking" with a anti-corruption layer. Inside of the layer you would use adapters and facades to wrap your legacy information sources.
More information about the anti-corruption layer:
In my particular implementation, EmployeeAccessService is called by a Repository. It's really a facade into the Anti-corruption layer. It delegates to the EmployeeAccessAdapter. The adapter fetches an object from the legacy model (which it gets from EmployeeAccessFacade),then passes it to the EmployeeAccessTranslator to transform the object from the legacy model to the domain object in my application's model.
EmployeeAccessService
public Employee findEmployee(String empID){ return adapter.findEmployee(empID); }
EmployeeAccessAdapter
public Employee findEmployee(String empID){ EmployeeAccessContainer container = facade.findEmployeeAccess(empID); return translator.translate(container); }
EmployeeAccessTranslator
public Employee translate(EmployeeAccessContainer container){ Employee emp = null; if (container != null) { employee = new Employee(); employee.setEmpID(idPrefix + container.getEmployeeDTO().getEmpID()); ...(more complex mappings)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With