#PhpirstAid - Replanteamiento de diseño de software

Replanteamiento de diseño de

Software

#PhpirstAid

#scbcn15 // #PhpirstAid

¡Bienvenidos!Soy Javier Ferrer González

@JavierCane en Twitter

Desarrollador web en @uvinum_es

Gañán en @CodelyTV

Agenda

Contexto Objetivos

Plan de acción Conclusiones

Problemas

Agenda

Exploración Objetivos del paciente

Tratamiento Diagnóstico final

Síntomas

Exploración1

Uvinum: Marketplace bebidas alcohólicas

El pacienteESTÁ VIVO

151.000.000Peticiones mensuales de media

Oficina

Web disponible en 14 países

5Años en activo

2M €Inversión total en 3 rondas

6 / 22Desarrolladores / Empleados totales

Objetivos del paciente2

1. Aumentar tolerancia a cambios (Ejemplo API)

Place your screen

Walking on water and developing software from a specification are easy if both are frozen

-Edward V. Berard

Las especificaciones CAMBIAN

-Sabiduría popular

Las especificaciones LAS CAMBIAMOS

2. Permitir una correcta implementación de test

Pirámide de test

Software testing ice-cream cone anti-pattern

3. Evitar muerte por deuda técnica (velocidad de desarrollo)

Muerte por deuda técnica

Deuda técnica

Complejidad accidental vs. Complejidad esencial

Complejidad esencial

Complejidad accidentalC

Tiempo

4. Sentir motivación por cómo hacemos lo que hacemos(Software Craftsmanship)

Síntomas3

1ª visita~Finales 2014

“El que avisa traiciona”

Síntomas

■ Falta de test■ Código altamente acoplado

■ Al framework (clases Controller y Model)■ A librerías externas■ A implementaciones concretas

■ Falta de modelado del dominio■ “Modelos” obesos■ Controladores obesos■ Código de difícil lectura

■ Falta de test => Reticencia al cambio/descontrol■ Alto acoplamiento => Poca cambiabilidad

Síntomas

Primer diagnóstico: “Borchenoso”

Tratamiento4

Tratamiento por etapas

Diseño“alto nivel” Procesos

Transferencia conocimiento

Replanteamiento diseño “bajo nivel”

■ OOP■ Clean Code■ Code Smells■ Refactoring■ Principios SOLID■ Object calisthenics

Etapa diseño a “bajo nivel”

■ Composition Over Inheritance

■ Tell don’t ask■ Ley de Demeter■ DRY■ YAGNI■ …

Clean Code - Naming

Clean Code Refactoring - Antes

Clean Code Refactoring - Después

■ Naming■ Guard clause■ Extract method■ Introduce

explanatory variable

Diseño “alto nivel” -> Domain-Driven Design

Arquitectura Hexagonal

■ Ports & Adapters■ Programación contra contratos / DIP FTW

■ Separación en capas■ Cambiabilidad

■ Regla de dependencia de fuera hacia dentro■ Bajo acoplamiento

■ Hexagonal Architecture, @fideloper

■ Hexagonal Architecture with PHP, @buenosvinos

■ Repo■ Application Services vs. Infrastructure Services vs. Domain

Services, @BenNadel

Takeaways

Capas Arquitectura Hexagonal

DDD - Agregados

DDD - Agregados - Clientes

DDD - Value Objects

Usando agregados y demás para listados

■ 1 Query por AR■ Agregados pequeños

=> Muchas queries■ MUCHAS:■ No vale cache■ Complejidad

Usando agregados y demás para listados

Usando Write Model para listados

DDD - Read Model

■ Ataca a la misma BBDD (progresivo)■ Permite violar restricciones del Write Model (WM)

para optimizar rendimiento■ No usa el dominio del WM para evitar pervertirlo■ Basado en DTOs

DDD - Read Model

Takeaways

■ Validation in DDD, @eulerfx

■ Read-models as a Tactical Pattern in DDD, @eulerfx

Read Model Composer

■ Finalidad: Agilizar desarrollo Read Model■ Reutilizar DTOs y “repositorios dependientes”■ Tradeoff que decidimos asumir :)

Read Model Composer Builder - Uso

Read Model

Composer

Builder -

Implementació

Read Model Composer Builder - Implementación

Read Model Composer Builder - Definición servicio

Read Model Composer Builder - Implementación Projector

RM Composer Builder - Implementación Projector

Read Model Composer Builder - Implementación Projector

RM Composer Builder - Implementación Joiner

RM Composer Builder - Diagrama de clases

Procesos -> Composer + CI

Sólo conseguiremos anular la reticencia al cambio con procesos que no generen

fricción innecesaria

Elementos introducidos

■ Actualización PHP 5.6■ Composer■ Continuous Deployment: Push a master => deploy

■ Único repositorio■ GitHub■ Capistrano

Transferencia conocimiento -> Rethinking Code

Cómo implicar al equipo

Sesiones Rethinking Code

■ Semanalmente■ 2 - 3 horas■ Equipo arquitectura■ Informales■ Casos prácticos

Sesiones Rethinking Code - Diseño “a bajo nivel”

1. Controllers menos Controllers2. SOLIDificando Verticomm3. Code Smells4. Refactoring, Clean Code & Tips5. Composition over Inheritance & Design Patterns6. Shotgun Surgery, DTOs & DIC

Hablar de SOLID en un entorno legacy

Takeaways

■ The SOLID Principles, @Tutsplus■ Code Smells & Refactorings, @RefactoringGuru■ Design Patterns, SourceMaking■ Screencasts de SOLID, @CodelyTV■ Ejemplos de código propio (involucrar, motivación)

Sesiones Rethinking Code - Diseño “a alto nivel” (1/2)

7. Teoría Hexagonal Architecture8. Workshop Hexagonal Architecture9. DDD Building Blocks - Value Objects

10. DDD Building Blocks - Values Objects Workshop11. DDD Building Blocks - Entities & Aggregates12. DDD Building Blocks - Entities & Aggregates Workshop

■ The Two Sides of Domain-Driven Design (DDD), @eulerfx

■ Repo Symfony MPWAR Edition, @Eloipoch y @SergiGP

■ Domain-Driven Design in PHP, @buenosvinos @theUniC y @KeyvanAkbary

■ Implementing Domain-Driven Design, @VaughnVernon

■ Ejercicios con contexto propio (acercar)

Takeaways

13. Dominio vs. Aplicación vs. Infraestructura y DI14. Use Read Model, stay legen...dary, y lo otro ya tal15. Read Model Workshop16. Pedidos conjuntos17. Event Driven Development

Sesiones Rethinking Code - Diseño “a alto nivel” (2/2)

Sesiones Rethinking Code - Testing

18. First tests exercises19. TDD with legos20. Setting up phpunit,

asserts and testing types21. …

■ TDD and Refactoring with LEGO, Bryan Beecham

Takeaways

Diagnóstico final5

■ Equipo arquitectura■ Composer■ SOLID■ Dependency Injector Container■ Arquitectura Hexagonal

■ Lógica desacoplada del framework■ Eventos

Puntos de inflexión

Errores cometidos

■ Gestión inicial del equipo de arquitectura■ Cuello de botella a la hora de resolver dudas

■ Intentar encajar Write Model en Read Model■ Subestimar impacto■ Subestimar Bounded Contexts

Si tu aplicación no es compleja, no te líes con DDD.Tira por CRUD y no hay problema.

-Dicho popular

¿Existen las “aplicaciones” complejas?

Una aplicación compleja tendrá partes donde NO merecerá la pena aplicar DDD

Pasito a Pasito Driven Development (PPDD)

Trabajo futuro

■ TDD (in progress)■ BDD

Agradecimientos7

Equipo técnico Uvinum

@Obokaman@PabloRos @EduFabra@_googol @Madu2789

¡Gracias!¿Preguntas? ¿Comentarios?

Contacto

■ @JavierCane

■ javier.mailserio@gmail.com

■ Codely.TV

■ SlidesCarnival Plantilla presentación■ Fideloper Imágenes Arquitectura Hexagonal■ Giphy GIFs Zoidberg■ WallpapersWide Wallpaper Zoidberg■ Arlo Belshee The 7 stages of naming■ Watirmelon Testing ice-cream cone anti-pattern■ Cañita Brava “El que avisa traiciona”

Créditos imágenes

#PhpirstAid - Replanteamiento de diseño de software

Software

Transcript of #PhpirstAid - Replanteamiento de diseño de software

Diseño de Tipografía

Diseño de juegos

diseño curricular

Diseño instruccional

Diseño ciclo

sobre diseño

Diseño Curricular Lerma

Diseño sustentable

Metodología del diseño

Diseño prospectivo

El replanteamiento de la ciberseguridad

Diseño Ambiental

Diseño Geométrico

Replanteamiento de La Prosperidad

PAPEO DISEÑO

Diseño Editorial II_0_Presentacion.pdf

.- Terreno debidamente acondicionado .- Replanteamiento de ...

Diseño ux

Consideracione diseño

Diseño Publicitario