architecture - DDD, capa anticorrupción, ¿cómo?

domain-driven-design rewrite

Question

En este momento, tenemos que construir una aplicación que se base en una heredada. El código para esa aplicación antigua debe ser desechado y reescrito, pero como suele ocurrir, en lugar de reescribirlo, necesitamos basar algo nuevo en él. Recientemente, decidimos ir a la ruta DomainDrivenDesign. Entonces, la capa anticorrupción podría ser una solución para nuestros problemas. Por lo que entiendo, de esta manera debería ser posible reescribir gradualmente la aplicación anterior.

Pero no puedo encontrar ningún buen ejemplo. Apreciaría CUALQUIER información.

Answer 1

Del libro de DDD (Diseño impulsado por dominio: abordando la complejidad en el corazón del software) por Eric Evans:

La interfaz pública de la CAPA DE ANTICORRUPCIÓN generalmente aparece como un conjunto de SERVICIOS, aunque ocasionalmente puede tomar la forma de una ENTIDAD.

y un poco mas tarde

Una forma de organizar el diseño del ANTICORRUPTION LAYER es como una combinación de FACHADAS, ADAPTADORES (ambos de Gamma et al. 1995) y traductores, junto con los mecanismos de comunicación y transporte que generalmente se necesitan para hablar entre los sistemas.

Por lo tanto, puede encontrar ejemplos mirando el patrón de adaptador y el patrón de fachada sugeridos.

Trataré de parafrasear lo que dijo Eric Evans, su capa anticorrupción aparecerá como servicios al exterior de su capa. Entonces, fuera de la capa anticorrupción, las otras capas no sabrán que están "hablando" con una capa anticorrupción. Dentro de la capa, usaría adaptadores y fachadas para envolver sus fuentes de información heredadas.

Más información sobre la capa anticorrupción:

• Anatomía de una capa anticorrupción, parte 1
• Construyendo la capa anticorrupción a menudo necesaria
• DDD - capa anticorrupción

Answer 2

En mi implementación particular, EmployeeAccessService es llamado por un Repositorio. Es realmente una fachada en la capa anticorrupción. Se delega al EmployeeAccessAdapter. El adaptador recupera un objeto del modelo heredado (que recibe de EmployeeAccessFacade), luego lo pasa al EmployeeAccessTranslator para transformar el objeto del modelo heredado al objeto de dominio en el modelo de mi aplicación.

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)