Diseño de software guía, Esquemas y mapas conceptuales de Programación de Bases de Datos

¡Descarga Diseño de software guía y más Esquemas y mapas conceptuales en PDF de Programación de Bases de Datos solo en Docsity!

V.

GUIA PARA

DIRECTIVOS Y TÉCNICOS V.

GUÍA COMPLETA

Software Design Guía completa

Este documento forma parte de las guías de onboarding de

Autentia. Si te apasiona el desarrollo de software de calidad

ayúdanos a difundirlas y anímate a unirte al equipo. Este es un

documento vivo y puedes encontrar la última versión, así como el

resto de partes que completan este documento, en nuestra web.

https://www.autentia.com/libros/

Esta obra está licenciada bajo la licencia Creative Commons

Attribution ShareAlike 4.0 International (CC BY-SA 4.0)

PRINCIPIOS Y PATRONES DEL DESARROLLO DE SOFTWARE

Los síntomas más evidentes son:

- Rigidez: el software se vuelve difícil de cambiar incluso en tareas

sencillas. Las estimaciones son cada vez más abultadas y cada

funcionalidad nueva cuesta horrores cuando antes era casi inmediata

- Fragilidad: muy relacionado con la rigidez, la fragilidad es la tendencia

a que el software se rompa en múltiples sitios cada vez que se hace

un cambio, incluso en partes que conceptualmente no tienen relación

ninguna las unas con las otras. Cuando subimos una nueva versión

que ha costado “sudor y lágrimas”, resulta que se rompen cosas que

aparentemente no tienen nada que ver con lo que hemos hecho.

- Inmovilidad o poca reutilización: cuando resulta imposible reutilizar

software de otros proyectos o incluso de otras partes del mismo

proyecto. Suele ocurrir porque el módulo que queremos reutilizar

tiene una mochila de dependencias demasiado grande como para

asumir el esfuerzo y el riesgo de desacoplarlo. Se piden cosas que

son prácticamente una copia de otras funcionalidades de las que ya

disponemos, sin embargo esto no parece ser una ventaja y cuesta

demasiado sacar lo común para reutilizarlo, tendiendose a copiar y

duplicar código.

- Viscosidad: la viscosidad en el ámbito del diseño se da cuando

es más sencillo hacer las cosas mal, hacer la “ñapa”, que tratar de

PRINCIPIOS Y PATRONES DEL DESARROLLO DE SOFTWARE

hacerlas por el camino trazado. La viscosidad en el entorno ocurre

cuando el ecosistema de desarrollo es lento e ineficiente en el más

amplio sentido de la palabra. Por ejemplo, cuando una vez tenemos la

funcionalidad terminada, hacerla llegar hasta producción supone una

auténtica aventura y se necesitan días (o semanas).

Software Design Índice

Principios y patrones del desarrollo de software

Parte 1: Principios y patrones del desarrollo de software

● Principios generales

• Principios S.O.L.I.D.
  • Single responsibility (SRP)
  • Open/closed (OCP)
  • Liskov substitution (LSP)
  • Interface segregation (ISP)
  • Dependency inversion (DIP)
• Don’t Repeat Yourself (DRY)
• Inversion of Control (IoC)
• You Aren’t Gonna Need It (YAGNI)
• Keep It Simple, Stupid (KISS)
• Law of Demeter (LoD)
• Strive for loosely coupled design between objects that interact
• Composition over inheritance
• Encapsulate what varies
• The four rules of simple design
• The boy scout rule
• Last Responsible Moment

● Design Patterns

• Patrones creacionales
  • Builder
  • Singleton
  • Dependency Injection
  • Service Locator
  • Abstract Factory
  • Factory Method
• Patrones estructurales
  • Adapter
  • Data Access Object (DAO)
  • Query Object
  • Decorator
  • Bridge
• Patrones de comportamiento
  • Command
  • Chain of Responsibility
  • Strategy
  • Template Method
  • Interpreter
  • Observer
  • State
  • Visitor
  • Iterator

● Patrones JEE

• Introducción
• Intercepting filter
• Front controller
• Dispatcher view
• Business delegate
• Value object
• Session facade

• Repositorios
• Factorías
• Diseño estratégico
• Introducción
• Bounded context
• Subdomains
• Introducción a las relaciones entre los Bounded Context
• Shared kernel
• Customer/Supplier
• Capa de Anticorrupción

● Command-Query Responsibility Segregation

• Command
• Query

● Clean Architecture

• Capas
  • Capa de dominio
  • Capa de aplicación
  • Capa de infraestructura
• Hexagonal architecture
  • Bloques de un sistema
  • Puertos y adaptadores
• Componentes
• Flujo de control
  • Usando servicios de aplicación.
  • CQRS sin Bus
  • CQRS con Bus
• Testing
• Event-driven architecture
  • Introducción
  • Evento de dominio
  • Contexto
• Event sourcing
• Consistencia eventual

Bibliografía

Lecciones aprendidas con esta guía

Parte 1

Principios y patrones del

desarrollo de software

PRINCIPIOS Y PATRONES DEL DESARROLLO DE SOFTWARE 13 ● I : Interface segregation. ● D : Dependency inversion. Aplicar estos principios facilitará mucho el trabajo, tanto propio como ajeno (es muy probable que nuestro código lo acaben leyendo muchos otros desarrolladores a lo largo de su ciclo de vida). Algunas de las ventajas de aplicarlo son: ● Facilitar el mantenimiento del código. ● Reducir la complejidad de añadir nuevas funcionalidades. ● Aumentar la reusabilidad de piezas y componentes. ● Mejorar la calidad del código y su comprensión.

Single responsibility (SRP)

El principio de responsabilidad única o single responsibility establece que un módulo de software debe tener una y solo una razón para cambiar. Esta razón para cambiar es lo que se entiende por responsabilidad. “Reúna las cosas que cambian por las mismas razones. Separe las cosas que cambian por diferentes razones.”

PRINCIPIOS Y PATRONES DEL DESARROLLO DE SOFTWARE 14 Este principio está estrechamente relacionado con los conceptos de acoplamiento y cohesión. Queremos aumentar la cohesión entre las cosas que cambian por las mismas razones y disminuir el acoplamiento entre las cosas que cambian por diferentes razones. Este principio trata sobre limitar el impacto de un cambio. Si existe más de una razón para cambiar una clase, probablemente tenga más de una responsabilidad. Otro posible “mal olor” es que tenga diferentes comportamientos dependiendo de su estado. Tener más de una responsabilidad también hace que el código sea difícil de leer, testear y mantener. Es decir, hace que el código sea menos flexible. Entre las ventajas de aplicar este principio encontramos que, si se necesita hacer algún cambio, éste será fácil de detectar ya que estará aislado en una clase claramente definida y comprensible. Minimizando los efectos colaterales en otras clases. Algunos ejemplos que encontramos en la vida real son: Si cambia la forma en que se compra un artículo, no tendremos que modificar el código responsable de almacenarlo. Si cambia la base de datos, no habrá que arreglar cada pedazo de código donde se utiliza. Para más detalle, ver el artículo [S.O.L.I.D.] Single responsibility principle / Principio de Responsabilidad Única en Adictos al Trabajo.

PRINCIPIOS Y PATRONES DEL DESARROLLO DE SOFTWARE 16 debería verse afectado y tener que modificarse. Y esa es realmente la esencia de este principio. Debería ser fácil cambiar el comportamiento de un módulo sin cambiar el código fuente de ese módulo. Esto no significa que nunca cambiará el código fuente. Lo que significa es que debemos esforzarnos por lograr que nuestro código esté estructurado de forma que, cuando el comportamiento cambie de la manera esperada, no debamos hacer cambios radicales en todos los módulos del sistema. Idealmente, podremos agregar el nuevo comportamiento, añadiendo código nuevo y cambiando poco o nada del código antiguo. La forma de implementar este principio en el mundo práctico, es a través del polimorfismo, ya sea por interfaces o clases abstractas. Para más detalle, ver el artículo [S.O.L.I.D.] Open-Closed Principle / Principio Abierto-Cerrado en Adictos al Trabajo.

PRINCIPIOS Y PATRONES DEL DESARROLLO DE SOFTWARE 17

Liskov substitution (LSP)

“Si se ve como un pato, hace cuac como un pato, pero necesita baterías, probablemente tengas la abstracción incorrecta.” La sustitución de Liskov nos dice que los objetos de un programa deberían ser reemplazables por instancias de sus subtipos sin alterar el correcto funcionamiento del programa. Básicamente, si en alguna parte de nuestro código estamos usando una clase, y esta clase es extendida, tenemos que poder utilizar cualquiera de las clases hijas y que el programa siga siendo válido. Esto nos obliga a asegurarnos de que cuando extendemos una clase no estamos alterando el comportamiento de la clase padre. Este principio nos ayuda a utilizar la herencia de forma correcta y nos muestra que no se debe mapear automáticamente el mundo real en un modelo orientado a objetos, ya que no existe una equivalencia unívoca entre ambos modelos. Para más detalle, ver el artículo [S.O.L.I.D.] Liskov substitution en Adictos al Trabajo.

PRINCIPIOS Y PATRONES DEL DESARROLLO DE SOFTWARE 19 Para más detalle, ver el artículo [S.O.L.I.D.] Interface Segregation Principle / Principio de segregación de interfaz en Adictos al Trabajo.

Dependency inversion (DIP)

El principio de inversión de dependencia nos dice que las entidades de software deben depender de abstracciones, no de implementaciones. A su vez, los módulos de alto nivel no deberían depender de los de bajo nivel. Ambos deberían depender de abstracciones.

PRINCIPIOS Y PATRONES DEL DESARROLLO DE SOFTWARE 20 Mediante este principio ocultamos los detalles de implementación, ganando en flexibilidad. Cuando estamos haciendo tests, podemos reemplazar dependencias reales por objetos mockeados. Gracias a esta flexibilidad, vamos a poder sustituir componentes sin que los clientes que los consumen se vean afectados ya que dependen de la abstracción y no de la implementación concreta. Lo que se pretende es que no existan dependencias directas entre módulos, sino que dependan de abstracciones. De esta forma, nuestros módulos pueden ser más fácilmente reutilizables. Es fundamental que la abstracción se defina en base a las necesidades del módulo o cliente y no en las capacidades de la implementación, de lo contrario, la abstracción estaría bastante acoplada a la implementación teniendo así menos flexibilidad. Para más detalle, ver el artículo [S.O.L.I.D.] Dependency inversion principle / Principio de inversión de dependencias en Adictos al Trabajo.