Ports are not abstracting adaptors
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Refactorización
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- javascript, node.js
- Área
- backend, backend-api-design
Línea de trabajo
Comienza con ports/Repository.js en la línea 6, enlazado en el issue, y sigue cómo su contrato está acoplado al esquema de DynamoDB. Usa la discusión del issue sobre el contrato de entrada/salida para evaluar el límite entre la lógica de dominio y los adaptadores; el trabajo está terminado cuando los cambios en el esquema de los adaptadores ya no requieren cambios correspondientes en el dominio.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
I used internally this sample for training with my team, and they got confused by the responsibility of ports. They struggled to understand the abstraction and to translate it to typescript. This issue is an attempt to make things more clear for developers new to hexagonal architecture.
I believe ports should enforce a contract between Domain logic and Adaptors, and protect changes to happen on domain logic when the implementation details present in Adaptors change.
Here the port is not only enforcing the contract but tied to the adaptor on itself.
for example, the Repository port is tied to the implementation of a DynamoDB table with a defined schema.
If we happen to change the database schema (changing key names, moving to a single table design, etc..), the port is not protecting the Domain logic from the implementation detail in the Adaptor. Moving to a single table design will imply changing Adaptor/ports and domain logic.
If we were in a typed language, the port would be represented by an Interface, that defines the contract (Input/Output), and the adaptor would implement this interface (the contract).
- Lenguaje dominante
- JavaScript
- Estrellas
- 159
- Forks
- 27
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
woocommerce/woocommerce-google-analytics-integration#699 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
t0ggles
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
nolimits4web/swiper#8240 · 1 comentario ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
Inter-Actief/amelink#131 ·