…es un sistema BDD

…es una herramienta de descomposición modular basada en la creación de historias de usuario

…consiste en separar los métodos en 2 tipos: comandos y consultas

…es una entidad que tiene sentido en tiempo de desarrollo

…es un componente que no tiene interfaz

…es una entidad que tiene sentido en tiempo de ejecución

…se puede obtener si los métodos que modifican un objeto devuelven dicho objeto

…separa los métodos de consulta de los métodos de escritura

…se consigue cuando se utiliza OSGI

…una interfaz oculta y un cuerpo visible

…interfaz visible y cuerpo oculto o protegido

…clases abstractas y concretas

…utiliza en el patrón CQRS

…es un módulo que carece de interfaz

…indica en qué tipo de métodos se inserta un aspecto

JMX

OSGI

Maven

Sistemas basados en el dominio

Máquinas virtuales

Estilo basado en generalización

…el rendimiento

…la reutilización

…el arranque rápido del desarrollo

…que un módulo no debe depender de otros módulos

…que un módulo solo debe comunicarse con los módulos próximos

…que un módulo debe depender de abstracciones, no de cosas concretas

…el estilo Big Ball of Mud

…la reutilización mediante polimorfismo

…el estilo Spring Roll

…se puede conseguir ejecutar un fragmento de código determinado antes o después de una serie de métodos

…se puede probar un fragmento de código de forma independiente

…se puede configurar un módulo en tiempo de ejecución

…advice y pointcuts

…una historia de usuario

…interfaces fluidos

…puede ser un cliente o un servidor, pero no ambos

…es un conjunto de sistemas dentro de un módulo que forma una secuencia de
interfaces

…es un conjunto de funcionalidades expuestas mediante una interfaz que ocupa un nivel N dentro del sistema

…la reutilización

…el principio de sustitución de Liskov

…el rendimiento

Mantenimiento

Reutilización

Flexibilidad en el inicio del desarrollo

Spring

Maven

JSP

…favorece el desarrollo incremental

…permite crear, arrancar y detener módulos en tiempo de ejecución

…se utiliza para definir el modelo de dominio del que depende el sistema

Es malo porque los módulos son muy pequeños

Es malo porque los módulos dependen de muchos otros módulos

Es bueno porque los módulos tienen una única responsabilidad

…la portabilidad

…la flexibilidad

…el rendimiento

Es malo porque un módulo puede tener varias responsabilidades

Es bueno porque un módulo no tiene cohesión con otros módulos

Es bueno porque los módulos no dependen de otros módulos

…facilita la comunicación del equipo mediante el uso de un lenguaje ubicuo

…aumenta el rendimiento del sistema

…permite módulos con baja cohesividad

…no puede haber ciclos

…los ciclos deben de identificarse mediante dependencias

…los ciclos se producen entre las capas N y N-1

…localizar la preocupaciones y responsabilidades

…que facilita la depuración del sistema

…fragmentar las preocupaciones en todos lo módulos

Es un patrón según el cual se almacenan los eventos de cambio de un estado

Consiste en comunicar el interfaz con la aplicación mediante eventos

Es un patrón para aumentar el acoplamiento

Winter

Spring

Big Ball of Mud

…se define como Development-Capacity-Integration

…se centra en identificar roles a partir de casos de uso

…genera pruebas a partir de historias de uso

Mocks o Stubs

Layers

AltCaps

…pueden utilizarse en sistemas complejos

…parten de un modelo de comportamiento y generan automáticamente el modelo de
datos

admiten un desarrollo rápido al evolucionar a partir del modelo de datos

...conlleva una separación física

..conlleva una separación lógica

...cada capa tiene una interfaz claramente definida

...está formado por un modelo de datos y un modelo de comportmiento independientes

...define el modelo de dominio a partir del esquema de la base de datos

...se centra en la creación de un modelo de dominio

...permite comunicar el aspecto general del sistema

...permite comunicar las relaciones de herencia

...mejora el rendimiento del sistema

...bases de datos NoSQL

...servicios web

...microservicios

...se define mediante la relación "depende de"

...define partes comunes estables, dejando las partes variables a los hijos

...proporciona módulos sin dependencias

...cada pieza de software está en una única capa

...cada capa contiene una única pieza de software

...las capas de alto nivel no pueden invocar funcionalidades de las capas de bajo nivel

Evitar las dependencias cíclicas

Evitar los módulos que dependen de otros módulos

Definir interfaces mediante el sistema OSGi

Un módulo no debe depender de otros módulos

Un módulo debe pedender de abstracciones, no de detalles

Un módulo debe depender de las impleetaciones , no de los interfaces

Se utiliza en sistemas complejos.

Es una combinación entre TDD y BDD

Se desarrolla a partir del modelo de datos y de las operaciones CRUD.

Un módulo debe implementar una interfaz abstracta que dependa de otro módulo

No puede haber dos hijos con el mismo padre

No puede haber bucles