Introducci贸n al curso

1

Introducci贸n al curso de Profesional de Arquitectura de Software

Atributos de calidad

2

Definici贸n

3

Atributos: Idoneidad funcional

4

Atributos: Eficiencia de ejecuci贸n

5

Atributos: Compatibilidad

6

Atributos: Usabilidad

7

Atributos: Confiabilidad

8

Atributos: Seguridad

9

Atributos: Mantenibilidad

10

Atributos: Portabilidad

11

Tensiones entre atributos

12

Analizando PlatziServicios

Patrones de arquitectura

13

Patrones monol铆ticos vs distribuidos

14

Patrones: Modelo Vista Controlador

15

Patrones: Capas

16

Patrones: Orientado a eventos / Provisi贸n de eventos.

17

Patrones: Microkernel - Plug-ins

18

Patrones: Comparte-nada

19

Patrones: Microservicios

20

Patrones: CQRS

21

Patrones: Hexagonal - Puertos y adaptadores

22

Patrones: Dise帽o orientado al dominio

23

Combinando patrones de arquitectura

24

Analizando nuevamente PlatziServicios

Dise帽o de una arquitectura

25

Pararse en hombros de gigantes

26

Herramientas y partes de un dise帽o: Tipos de conectores

27

Conectores: Llamado asincr贸nico / sincr贸nico. Modelo Cliente servidor.

28

Conectores: Enrutador, difusi贸n

29

Conectores: Pizarra, repositorio, colas, modelo PUBSUB

30

Escenarios y t谩cticas

31

Escenarios: Disponibilidad, detecci贸n, reparaci贸n

32

Escenarios: Reintroducci贸n y prevenci贸n

33

Escenarios: Mantenibilidad

34

Escenarios: Prevenir efectos domin贸 y diferir enlace

35

Escenarios: Eficiencia de ejecuci贸n

36

Escenarios: Seguridad

37

Escenarios: Capacidad de prueba

38

Escenarios: Usabilidad

39

Validar las decisiones de dise帽o: Arquitectura en evoluci贸n

40

脷ltimo an谩lisis a PlatziServicios

Modelado y documentaci贸n de arquitectura

41

C贸mo comunicar la arquitectura: Vistas y Puntos de vista

42

Documentaci贸n vs implementaci贸n

43

Conclusiones del curso

A煤n no tienes acceso a esta clase

Crea una cuenta y contin煤a viendo este curso

Escenarios: Prevenir efectos domin贸 y diferir enlace

34/43
Recursos

Aportes 10

Preguntas 2

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesi贸n.

Apuntes:

Prevenir efectos domin贸. Trabaja estrictamente con las dependencias. Es decir, cu谩ndo podemos detectar que un cambio generar铆a problemas en otros m贸dulos u otras dependencias.
鈥 Ocultar informaci贸n. Cualquier m贸dulo u objeto que dise帽emos, tenga la capacidad de ocultar cierta parte de la informaci贸n para que los agentes externos no dependan de esa informaci贸n puntual sino de una interfaz clara que no puedan cambiar por m谩s que la informaci贸n cambie. De esta forma podemos garantizar que, si el cambio de la informaci贸n es importante, los dependientes no necesiten cambiar porque est谩n pasando por una interfaz que no cambi贸.
鈥 Mantener la interfaz. Si tengo un servicio que hace algo, la dependencia a ese servicio va a ser a trav茅s de una interfaz clara, de lo contrario cualquier acci贸n cu谩ndo cambie puede poner en riesgo el m贸dulo.
鈥 Restringir comunicaci贸n. Para generar sistemas que est茅n acoplados de forma ligeras, en vez de conocer las dependencias de tus dependencias, siempre te limites a tus dependencias directas, de esta forma cualquier cambio en la forma que tus dependencias trabajan no afecta al m贸dulo en el que est谩s trabajando.
鈥 Intermediarios. Hablamos de un punto d贸nde podamos compatibilizar a un m贸dulo con otro y si dejan de ser compatibles, estos intermediarios puedan servir como punto de compatibilidad.

Diferir enlace. Habla sobre c贸mo podemos hacer para que un cambio en nuestro c贸digo no requiera desplegar toda la aplicaci贸n completa.
鈥 Registro en ejecuci贸n. Cuando un m贸dulo o servicio depende de otro, si dependen fuertemente van a requerir estar compilados juntos. Si nosotros podemos diferir esa compilaci贸n y que se registre un servicio en momento de ejecuci贸n, es decir que se ponga disponible a sus dependencias en el momento de ejecuci贸n, podemos hacer que estos servicios se puedan desplegar independientemente.
鈥 Archivos de configuraci贸n. Van a servir para en momento de ejecuci贸n saber c贸mo conectar varias partes. Es imprescindible que nuestros m贸dulos dependan de interfaces y no de implementaciones espec铆ficas.
鈥 Polimorfismos. Un objeto pueda comportarse de forma diferente en base a su estado. A trav茅s del polimorfismo podemos postergar la forma en que se resuelve un problema dependiendo de qu茅 instancia del objeto ser谩.
鈥 Reemplazo de componentes. Tener la capacidad de desplegar un componente y luego desplegar su reemplazo, o quiz谩s otro componente que respete esa interfaz, y que todo el resto de nuestra aplicaci贸n no necesite cambiar.
鈥 Adherir a protocolos. Nos permite tener un protocolo claro entre dos m贸dulos y no necesitar saber la instancia espec铆fica o el tipo espec铆fico de un m贸dulo.

Ley de Demeter o el principio de menor conocimiento, esta ley dice que para generar sistemas que est茅n acoplados de forma ligera en vez de conocer las dependencias de tus dependencias siempre te limites a hablar con tus dependencias directas. De esta forma cualquier cambio en la forma en la que tus dependencias trabajan no afecta al modulo que estas trabajando.

Escenario: Mantenibilidad

Estimulo: Pedido de cambio / Nuevo requerimiento

  • Prevenir efectos domino
    • Ocultar informaci贸n
    • Mantener la interfaz
    • Restringir comunicaci贸n
    • Intermediarios
  • Diferir enlace
    • Registro en ejecuci贸n
    • Archivos de configuraci贸n
    • Polimorfismo
    • Remplazo de componentes
    • Adherir a protocolos

Cambios sem谩nticos. Si la sem谩ntica de lo que hacemos cambia, el modulo que lo implementa tambi茅n cambiara. Se relaciona con el sentido. Cambia la l贸gica.
Cambios sint茅ticos. Cambios en la secuencia de lo que se hace. Los cambios de 鈥淢antener la interfaz鈥 funcionan aqu铆. Se relaciona con la estructura.

semantico: que se relaciona con el sentido
sintactico: que se relaciona con la estructura

Estos temas son un resumen de lo expuesto en este modulo鈥

 -------------------------------------------------
*)PRINCIPIOS GRASP
  +Encapsulamiento
  +Acoplamiento
  +Cohesion
  +Ley Demeter
  +Separation of Concerns
  +Invertion of Control
  +Don't Repeate Yourself
  +Keep it Simple Stupid
 -------------------------------------------------
*)PRINCIPIOS SOLID
  +Single Responsability Principal
  +Open/Closed Principal
  +Liskov Sustitution Principal
  +Interface Segregation Principal
  +Dependention Invertion Principal
 -------------------------------------------------
*)PATRONES ARQUITECTONICOS
  +Circuit Breaker
  +Publisher/Suscriber
  +Dashboard
  +Plugins
 -------------------------------------------------
*)PATRONES DISEO SOFTWARE
  ->CREACIONALES<-
  +Singleton
  +Prototype
  +Builder
  +Factory Method
  +Abstract Factory
  +Object Pool
  ->ESTRUCTURALES<-
  +Adapter
  +Bridge
  +Composite
  +Decorator
  +Facade
  +Flyweight
  +Proxy
->COMPORTAMIENTO<-
  +Iterator
  +Command
  +Observer
  +Tempalte Method
  +Strategy
  +Chain of Responsability
  +Interpreter
  +Mediator
  +Moment
  +Null Object
  +State
  +Visitor
 -------------------------------------------------

猸愶笍 Excelente 猸愶笍

猸愶笍猸愶笍猸愶笍猸愶笍猸愶笍

COMPLETO:
Familias de t谩cticas:
1.- Confinar modificaciones. Las t谩cticas van a intentar trabajar sobre nuestros m贸dulos para que cada cambio que nos pidan est茅 confinado a s贸lo un m贸dulo. Cuando logramos esto logramos que las dependencias entre m贸dulos sean m谩s ligeras y el cambio que nos proponen no afecte a muchas partes del sistema.
a) Coherencia sem谩ntica. Habla de la relaci贸n entre las responsabilidades de los m贸dulos. Hablamos de acoplamiento y cohesi贸n. Si logramos encontrar la cohesi贸n en un m贸dulo entonces vamos a poder hacer que ese m贸dulo sea m谩s mantenible. De lo contrario es posible que ese m贸dulo cambie por diferentes razones.
Abstraer servicios comunes. Cuando encontramos que la aplicaci贸n tiene servicios m谩s gen茅ricos de no necesario podemos abstraerlos a un punto com煤n y que las dependencias vayan de los m贸dulos cohesivos a un servicio o modulo externo.
b) Generalizar. Al generalizar un m贸dulo podemos separar lo espec铆fico de lo gen茅rico.
c) Limitar opciones disponibles. Limitar el rango de modificaci贸n nos ayuda a que sea m谩s mantenible.
d) Anticipar cambios. Prepararnos para alg煤n cambio que nosotros mismo sepamos que se deber谩 de dar en el futuro tomando en cuenta una estrategia sobre como incorporar el nuevo cambio. Los patrones de dise帽o suelen estar orientados a esto (Patr贸n estrategia).
2.- Prevenir efectos domino. Trabaja estrictamente con las dependencias, es decir cuando podemos detectar que un cambio generar铆a problemas en otros m贸dulos o dependencias.
Prevenir efectos domin贸. Trabaja estrictamente con las dependencias. Es decir, cu谩ndo podemos detectar que un cambio generar铆a problemas en otros m贸dulos u otras dependencias.
鈥 Ocultar informaci贸n. Cualquier m贸dulo u objeto que dise帽emos, tenga la capacidad de ocultar cierta parte de la informaci贸n para que los agentes externos no dependan de esa informaci贸n puntual sino de una interfaz clara que no puedan cambiar por m谩s que la informaci贸n cambie. De esta forma podemos garantizar que, si el cambio de la informaci贸n es importante, los dependientes no necesiten cambiar porque est谩n pasando por una interfaz que no cambi贸.
鈥 Mantener la interfaz. Si tengo un servicio que hace algo, la dependencia a ese servicio va a ser a trav茅s de una interfaz clara, de lo contrario cualquier acci贸n cu谩ndo cambie puede poner en riesgo el m贸dulo.
鈥 Restringir comunicaci贸n. Para generar sistemas que est茅n acoplados de forma ligeras, en vez de conocer las dependencias de tus dependencias, siempre te limites a tus dependencias directas, de esta forma cualquier cambio en la forma que tus dependencias trabajan no afecta al m贸dulo en el que est谩s trabajando.
鈥 Intermediarios. Hablamos de un punto d贸nde podamos compatibilizar a un m贸dulo con otro y si dejan de ser compatibles, estos intermediarios puedan servir como punto de compatibilidad.
3.- Diferir enlace. Habla sobre c贸mo podemos hacer para que un cambio en nuestro c贸digo no requiera desplegar toda la aplicaci贸n completa.
鈥 Registro en ejecuci贸n. Cuando un m贸dulo o servicio depende de otro, si dependen fuertemente van a requerir estar compilados juntos. Si nosotros podemos diferir esa compilaci贸n y que se registre un servicio en momento de ejecuci贸n, es decir que se ponga disponible a sus dependencias en el momento de ejecuci贸n, podemos hacer que estos servicios se puedan desplegar independientemente.
鈥 Archivos de configuraci贸n. Van a servir para en momento de ejecuci贸n saber c贸mo conectar varias partes. Es imprescindible que nuestros m贸dulos dependan de interfaces y no de implementaciones espec铆ficas.
鈥 Polimorfismos. Un objeto pueda comportarse de forma diferente en base a su estado. A trav茅s del polimorfismo podemos postergar la forma en que se resuelve un problema dependiendo de qu茅 instancia del objeto ser谩.
鈥 Reemplazo de componentes. Tener la capacidad de desplegar un componente y luego desplegar su reemplazo, o quiz谩s otro componente que respete esa interfaz, y que todo el resto de nuestra aplicaci贸n no necesite cambiar.
鈥 Adherir a protocolos. Nos permite tener un protocolo claro entre dos m贸dulos y no necesitar saber la instancia espec铆fica o el tipo espec铆fico de un m贸dulo.

Cuando hablamos de ocular informaci贸n hablamos de encapsulamiento? Por ejemplo

<h3>Prevenir efectos Domino:</h3>

Los cambios provocan otros cambios no previstos en el sistema.
T谩cticas:

  • Ocultar Informaci贸n
  • Mantener la Interfaz
  • Restringir Comunicaci贸n
  • Intermediarios
<h3>Diferir enlace:</h3>
  • Registro en ejecuci贸n
  • Archivos de Configuraci贸n
  • Polimorfismo
  • Reemplazo de Componentes
  • Adherir a Protocolos