Ex Posicion

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 4

Uno de los factores más importantes que debe considerar es por qué necesita un

nuevo software. ¿Cómo puede esperar de manera realista elegir el mejor software para
su organización si no conoce las necesidades específicas que desea que satisfaga?
La clave aquí no es solo identificar sus necesidades actuales. Debe pensar cuáles
serán las necesidades de su empresa al menos varios años después. No desea invertir
en software que su negocio superará rápidamente, una solución que no es lo
suficientemente versátil para adaptarse a condiciones cambiantes o software que no es
escalable, después de todo.

Principio de responsabilidad única


El principio de responsabilidad única (SRP) establece:
Una clase debe tener una y una sola razón para cambiar, lo que significa que una clase
debe tener solo un trabajo.

Principio abierto-cerrado
Principio abierto-cerrado (S.R.P.) establece:
Los objetos o entidades deben estar abiertos por extensión, pero cerrados por
modificación.
Esto significa que una clase debe ser ampliable sin modificar la clase en sí.

Principio de sustitución de Liskov


El principio de sustitución de Liskov establece:
Digamos que q(x) sea una propiedad demostrable sobre objetos de x, de tipo T.
Entonces, q(y) debe ser demostrable para los objetos y, de tipo S, donde S es un
subtipo de T.
Esto significa que cada subclase o clase derivada debe ser sustituible por su clase
base o clase principal.

Principio de segregación de interfaz


El principio de segregación de interfaz establece:
Un cliente nunca debe ser forzado a implementar una interfaz que no usan ni los
clientes no deben ser forzados a depender de métodos que no usan.

Principio de inversión de dependencia


El principio de inversión de dependencia establece:
Las entidades deben depender de abstracciones, no de concreciones. Indica que el
módulo de alto nivel no debe depender del módulo de bajo nivel, sino que deben
depender de las abstracciones.
Este principio permite el desacoplamiento.

Don’t Repeat Yourself (No te repitas)


Este principio (conocido como DRY) se explica por sí mismo: debes evitar al máximo
grado posible la repetición de código. Partiendo de este principio se han creado un
montón de maneras de reutilizar lo que ya hemos programado, piénsalo un poco:
funciones, módulos, bibliotecas, clases, prototipos, herencia, composición, macros,
saltos (goto).
Estas son sólo algunas maneras de evitar la repetición, claro, cada una de las
estrategias anteriores lo logra a su manera y añade otras ventajas y desventajas.
¿Por qué es importante? Existen varias razones:
 Hace el código más mantenible. Evitar la repetición de código permite que si
alguna vez cambia la funcionalidad que estás repitiendo, no lo tengas que hacer
en todos los lugares en los que lo repetiste.
 Reduce el tamaño del código. Esto lo hace más legible y entendible, porque hay
menos código que entender. Los procesos para evitar la repetición implican
nombrar el pedazo de código que estás reutilizando para identificarlo, esto hace
el código más legible si lo nombraste bien.
 Ahorra tiempo. Al tener pedazos de código disponibles para reutilizarlos, en el
futuro estás más preparado para lograr lo mismo en menos tiempo.

KISS
“Keep it simple[,] stupid”: hay discrepancias sobre si esta frase significa: “Déjalo simple,
estúpido” o “Mantenlo estúpidamente simple”. Este principio establece que el código, el
diseño, la documentación, todo lo relacionado con el software, debe ser tan simple
como sea posible.
Los programadores tendemos a complicar las cosas. Nos piden un formulario sencillo y
queremos hacer un generador de formularios que soporte este y todos los formularios
en el futuro. No tenemos ni 100 usuarios y ya queremos usar Kubernetes. Necesitamos
un simple binding de datos y queremos meter Angular 7, Ionic 3 y 250 bibliotecas más.

Este principio establece que:


 Nuestro software en general debería tener tan pocos componentes (y por lo
tanto líneas) como sea posible.
 No deberíamos tener funcionalidades que no se ocupen actualmente “por si en
el futuro se ocupan”.
 La documentación debe tener la información estrictamente necesaria.
 El código debe ser lo más obvio y sencillo posible. Se deben evitar esas líneas
que sólo sirven para presumir lo inteligente que eres.
 El diseño debe mantener la estructura simple, siempre que se pueda.
¿Por qué es importante? Las siguientes son algunas de las razones que justifican la
existencia de este principio:
 Proyectos más mantenibles. Hay mucho menos que explicar al mantener las
cosas simples. El código es más fácil de mantener y actualizar.
 menos documentación. Hay menos cosas raras que documentar al hacer el
código fácil, sin trucos de listillos que nadie entiende.
 Debugging más rápido. Al reducir la complejidad se pueden encontrar los errores
más rápidamente.
 Mayor rendimiento económico. Los tres efectos anteriores permiten que la
inversión económica inicial en el código creado tenga mayores rendimientos.
Este es uno de los principios más difíciles de aplicar, si no es que el más difícil. Hacer
algo simple para los demás requiere de pensar las cosas el tiempo suficiente, de tener
la experiencia técnica necesaria para evitar intentar matar una mosca con un cañón (o
investigar y tener la capacidad de aprender). A final de cuentas la simplicidad es la
sofisticación más avanzada.

Domain Driven Design (DDD)


DDD nos ayuda, en primer lugar, a definir exhaustivamente el dominio. Nos permite
también conocer de modo extenso el problema de negocio de manera que podamos
dividirlo en subdominios con el objetivo de maximizar el desacoplamiento entre los
subdominios y lograr así soluciones modulares, que premian la adaptabilidad de cada
subdominio y, por lo tanto, la adaptabilidad de la solución en general.
1. Domain
 Domain es el problema de negocio que analizamos, para dar una solución
basada en software. El Domain puede dividirse en Domains más pequeños.
Lo que lo convierte en un concepto fractal. Además DDD nos indica los
distintos tipos de Domain que existen, los clasifica en base a la relevancia
que tienen para la estrategia de la empresa.
2. Ubiquitous Language
 Este es un concepto muy importante en DDD. Como ya decía Vygotsky, "el
lenguaje es un regulador del pensamiento", y DDD recupera la importancia
del lenguaje. Pero, en esta ocasión, para pensar, analizar y definir el Domain.
 DDD define el Ubiquitous Language como la jerga que los expertos de
negocio emplean de manera natural para articular y para definir su problema
de negocio, su Domain.
3. Bounded Context
 Bounded Context es la herramienta que nos entrega DDD para acotar los
distintos Domains. Una vez estos son identificados a partir de las
discrepancias antes descritas, tenemos que trazar un círculo a su alrededor
para dejarlos explícitamente identificados, ese círculo acota el Bounded
Context. El siguiente paso es identificar el equipo de negocio e IT expertos
en ese Domain, en ese Bounded Context y responsabilizarse de la propuesta
de valor de la solución para ese problema de negocio.
4. Context Mapping
 Los Bounded Context necesitan interactuar con otros Bounded Context.
Comercial no puede estar aislado de mantenimiento, necesitan mandarse
mensajes, interaccionar. Context Mapping nos ayudan identificar y
especificar las relaciones existentes entre los Bounded Context.
 Dichas relaciones cumplirán los patrones de relación que explica DDD y
dicho patrón tendrá mayor o menor impacto en la independencia de unos
Bounded Context con otros. Mediante la consciencia sobre los patrones de
relación entre los Bounded Context, cada equipo puede establecer los
mecanismos técnicos – también explicados por DDD – para “proteger” su
independencia de otros Bounded Context.

También podría gustarte