#PhpirstAid - Replanteamiento de diseño de software

Replanteamiento
de diseño de
Software

#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 paciente
ESTÁ VIVO

151.000.000
Peticiones mensuales de media

Oficina
Web disponible en 14 países

5
Años en activo
2M €
Inversión total en 3 rondas
6 / 22
Desarrolladores / Empleados totales

Objetivos del paciente2

1. Aumentar tolerancia a cambios (Ejemplo API)
Placeyourscreenshot
here

“
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 accidental
Complejidadsistema
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

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

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

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
Compos
er
Builder
-
Implem
entació
n
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

“
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 Controllers
2. SOLIDificando Verticomm
3. Code Smells
4. Refactoring, Clean Code & Tips
5. Composition over Inheritance & Design Patterns
6. 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 Architecture
8. Workshop Hexagonal Architecture
9. DDD Building Blocks - Value Objects
10. DDD Building Blocks - Values Objects Workshop
11. DDD Building Blocks - Entities & Aggregates
12. 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 DI
14. Use Read Model, stay legen...dary, y lo otro ya tal
15. Read Model Workshop
16. Pedidos conjuntos
17. Event Driven Development
Sesiones Rethinking Code - Diseño “a alto nivel” (2/2)

Sesiones Rethinking Code - Testing
18. First tests exercises
19. TDD with legos
20. Setting up phpunit,
asserts and testing types
21. …

■ 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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a #PhpirstAid - Replanteamiento de diseño de software

Similar a #PhpirstAid - Replanteamiento de diseño de software (20)

Más de Javier Ferrer González

Más de Javier Ferrer González (7)

#PhpirstAid - Replanteamiento de diseño de software