Historia de una gran bola de lodo escrita en javascript. Parte I

Charla impartida en la CommitConf 2019.
Estas slides sólo tienen utilidad si se ve la charla. Cuando salga la grabación la adjuntaré aquí.

Redumen
Javascript es sin dudas el lenguaje más versátil y popular de la era de Internet y a la vez el que más disciplina y fundamentos de ingeniería de software exige para escribir código mantenible.

Me gustaría contaros cómo Javascript y Node.js nos permitieron hace 7 años añadir funcionalidades a velocidad de crucero como si no hubiese mañana y competir con los principales productos del ecosistema social media.

También me gustaría contaros cómo esa dinámica nos llevo a escribir una gran bola de lodo y cómo tuvimos que pagar la deuda y sus no pocos intereses para poder reaccionar a los cambios del mercado y la evolución del stack.

En algún punto entendimos que arquitectura hexagonal y domain driven design serían nuestro aliados. ¿Cómo aplicas todo esto con un equipo pequeño y al que todo esto le viene de nuevas sin dejar de añadir valor a tus clientes? La respuesta a esta pregunta será el centro de esta charla. Hablaremos de cómo nos tuvimos que reciclar como equipo, cuál fue nuestro plan de evolución de la arquitectura y cómo typescript jugó un papel fundamental.

De todas estas etapas veremos algunos ejemplos de código espagueti, implementación de clean architecture con javascript y arquitectura hexagonal y DDD con typescript, todos conviviendo en el mismo monolito.

Como el título deja ver esta historia tiene segunda parte y aún se está escribiendo, tratará sobre cómo estamos viviendo el desacoplado del monolito.

Transcript

1. Alfredo Artiles Co-founder & CTO @aartiles24 Historia de una Gran Bola de Lodo escrita en JavaScript Parte I
2. ๏Cubano de nacimiento y cordobés de adopción. ๏Lic. en Ciencias de la Computación por la Universidad Central de Las Villas ๏Investigador en el grupo investigación EATCO de la UCO ๏Emprendedor en proyectos como MayoCordobés, e24Presenter, FollowFriday.com y Audiense ๏Combino mi pasión por el desarrollo de software con el ajedrez, el deporte y mi familia ¿Quién Soy?
3. Audiense Insights
4. Agenda ๏ ¿Qué factores influyen en nuestra velocidad de entrega de software? ๏ Historia de nuestra Gran Bola de Lodo ๏ Enséñame tus Hexágonos
5. Strive for Awesomeness
6. ¿Qué factores influyen en la velocidad de entrega de software?
7. Métricas de Rendimiento
8. Métricas de Rendimiento < 1día > 1/día < 1hora < 15%
9. Fuente: https://cloud.google.com/devops/state-of-devops/
10. Entrega Continua https://flic.kr/p/9RqUnZ
11. Nuestros Miedos https://flic.kr/p/uDCCVE
12. Miedo a Liarla Parda https://flic.kr/p/eeoHep
13. Miedo a que No Funcione https://flic.kr/p/kkVZ
14. Miedo a Delegar https://flic.kr/p/8orAW7
15. Miedo a Tocar https://flic.kr/p/9H1HZT
16. Miedo a la Imperfección https://flic.kr/p/uB715f
17. Fuente: https://trunkbaseddevelopment.com Trunk Based Development
18. La solución a nuestros miedos ๏Mantenibilidad del código ๏Arquitectura débilmente acoplada ๏Monitorización ๏Despliegues automáticos ๏Integración continua ๏Trunk based development
19. Historia de nuestra Gran Bola de Lodo
20. Nuestro Monolito https://flic.kr/p/ngKjxo
21. ¿Cuándo deja de ser bueno un monolito? ๏Necesidades de escalabilidad independiente de diferentes componentes del dominio ๏Diferentes componentes o módulos necesitan escribirse en diferentes lenguajes ๏Necesidad de despliegues independientes ๏Big ball of mud
22. https://twitter.com/simonbrown/status/847339104874381312
23. Nuestra gran Bola de Lodo https://flic.kr/p/aMeqJn
24. Code is going to get messy. There is no shame in that. Seeing code as messy is a sign that you have learned something. Kent Beck
25. Geología del Software https://flic.kr/p/vLbPwW
26. Big design up front is dumb. Doing no design up front is even dumber. Dave Thomas
27. ¿Compensa el coste de la calidad? Fuente: https://martinfowler.com/articles/is-quality-worth-cost.html
28. Programming is not about building software; programming is about designing software. Jack W. Reeves, 1992
29. El rol del arquitecto de software
30. El rol del arquitecto de software
31. Arquitectura Hexagonal
32. Onion Architecture
33. Event Storming
34. Context Mapping
35. Brotes de Hexágonos
36. Anti- corruption Layers
37. Lecciones Aprendidas ๏No podemos olvidarnos del diseño previo ๏El diseño es el código ๏El coste de la calidad compensa ๏Arquitecto no es un rango ni un rol individual ๏La solución a los problemas de un monolito no siempre es microservicios
39. Lógica de Negocio en los Controladores
42. Arquitectura Hexagonal Simple
44. Factoría de acción inyecta implementación de infraestructura Implementación de acción sólo conoce interfaz
45. Arquitectura Hexagonal sin Modelado del Dominio
46. Controlador sólo conoce acción
47. Factoría inyecta demasiados colaboradores
48. Implementación de action sólo conoce interfaces de los colaboradores pero coordina demasiados
49. Sigue…
50. Arquitectura Hexagonal Y DDD en Typescript
51. Estructura de carpetas de módulos de nuestro bounded context Reports
52. App Service sólo conoce interfaz del repositorio
53. El dominio está totalmente desacoplado de los detalles de infraestructura y casos de usos
54. Implementación del repositorio con MongoDB Único punto donde nos acoplamos con 3ros
55. Implementación del repositorio en memoria
56. Uso de los app services desde el legacy en javascript usando el código transpilado
57. Tests unitarios con implementación en memoria de repositorios
58. $ npx arkit -d Reports/src/CustomRankings/ -f Reports/src/ CustomRankings/application/GetCustomRanking.ts -o ~/deps.png
60. Hay miles de métodos pero sólo unos pocos principios. Quien entiende los principios podrá elegir sus propios métodos. Quien ignora los principios fracasará con cualquier método. Harrington Emerson
61. ¡Gracias! @aartiles24