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

No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

Patrones: Dise帽o orientado al dominio

22/43
Recursos

El dise帽o orientado al domino no lleva a orientar nuestra aplicaci贸n y su dise帽o a partir del lenguaje del negocio.

Aportes 23

Preguntas 2

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

o inicia sesi贸n.

Creo que si bien los conceptos son bien explicados en general para todos los patrones faltan ejemplos de la vida real que permitan tener mas claridad.

Apuntes:

Dise帽o orientado al dominio

Lo que hacemos es guiar nuestra aplicaci贸n y el dise帽o a trav茅s del uso del lenguaje com煤n entre el negocio y el desarrollo. El obtener ese lenguaje del negocio y el poder hacer aplicaciones que est茅n concentradas en eso mucho m谩s que lo que est谩n concentradas en detalles t茅cnicos. Va m谩s all谩 de una sola aplicaci贸n, nos dice que busquemos modularizar nuestro sistema a trav茅s de los bounded context, que tratan de encontrar d贸nde el lenguaje cambia de sentido.

  • Domain Driven Design (DDD) es un nuevo enfoque de desarrollo de software.

  • Representa distintas claves, terminolog铆ay patrones utilizados para desarrollar software donde** el dominio es lo m谩s central e importante de una determinada organizaci贸n**.

  • Sus principios se basan en:

  • Colocar los modelos y** reglas de negocio de la organizaci贸n, en el core de la aplicaci贸n**

  • Basar nuestro dominio complejo, en un modelo de software.

  • Se utiliza para tener una mejor perspectiva a nivel de colaboraci贸n entre expertos del dominio y los desarrolladores, para concebir un software con los objetivos bien claros.

**Beneficios:
**

  • Comunicaci贸n efectiva entre expertos del dominio y expertos t茅cnicos a trav茅s de Ubiquitous Languge.

  • Foco en el desarrollo de un 谩rea dividida del dominio (subdominio) a trav茅s de Bounded Context鈥檚.

  • El software es m谩s cercano al dominio, y por lo tanto es m谩s cercano al cliente.

  • C贸digo bien organizado, permitiendo el testing de las distintas partes del dominio de manera aisladas.

  • L贸gica de negocio reside en un solo lugar, y dividida por contextos.
    Mantenibilidad a largo plazo.

**Inconvenientes **:

  • Aislar la l贸gica de negocio con un experto de dominio y el equipo de desarrollo suele llevar mucho esfuerzo a nivel tiempo.

  • Necesitamos un experto de dominio

  • Una curva de aprendizaje alta, con patrones, procedimientos,鈥

  • Este enfoque solo es sugerido para aplicaciones donde el dominio sea complejo, no es recomendado para simples CRUD鈥檚.

Est谩 informaci贸n la saqu茅 de https://medium.com/@jonathanloscalzo/domain-driven-design-principios-beneficios-y-elementos-primera-parte-aad90f30aa35

les recomiendo leer est茅 art铆culo.

Pienso que 6 minutos se quedan cortos para explicar DDD. En este caso, hay todo un sumario de terminlog铆as y conceptos que no est谩n ligados puramente a arquitectura.

Ser铆a espectacular tener un curso aplicado 煤nicamente a DDD.

Realmente estas clases son muy buenos pero nos deja cortos para poder pensar en asumir el rol de arquitecto en una empresa.
Parecen cursos de introduccion pero propongo una carrera de Arquitecto de software en platzi.

Patrones: Dise帽o orientado al dominio

Se gu铆a la aplicaci贸n y dise帽o a trav茅s del uso del lenguaje com煤n entre el negocio y el desarrollo. Se trata de modelar el concepto y no tanto en especificar si es un servicio, factory o otro tipo de patron.


Los Contextos delimitados: (bounder context) Busca modularizar el sistema, estos contextos tratan de buscar en donde el lenguaje cambia de sentido.


Se concentra much en trabajar con el negocio y entender profundamente cual es el lenguaje que usan. Hay mucho valor en la sem谩ntica y mucho valor en la forma que se dise帽a y se conecta VS la forma en la que el negocio piensa.

------------ Dise帽o orientado al Dominio

  • El dise帽o orientado al dominio genera m贸dulos que se puedan desplegar por separado

  • Guiar la aplicaci贸n atrav茅s del uso del lenguaje com煤n entre el negocio y el desarrollo

  • Concentrar en ello las aplicaciones y no en el detalle t茅cnico. Dice que se debe intentar modularizar la aplicaci贸n en Bounded Context.

  • Tratan de encontrar donde el lenguaje cambia de sentido -> bounded context

  • En el contexto de ventas el significado de producto es otro en comparaci贸n con el significado de inventarios.

  • Aprovecha la separaci贸n sem谩ntica (propuesta por el negocio) para as铆 separar nuestra aplicaci贸n

Me gustar铆a trabajar algunos de los ejemplos para entender mejor la teor铆a.

Dominio
Es toda la informacion del negocio, del problema que queremos resolver, es la corazon de nuestro DDD.

Ubiquitous Language
Es la comunicaci贸n efectiva entre los desarrolladores y los expertos del dominio. Un lenguaje com煤n, que sea representado en el dominio, tanto como en los bounded contexts(subdominios), para asi lograr desarollar un software con los objetivos bien claros

Para mi es muy poco claro

Lo que se hace en un dise帽o orientado al dominio es llevar la aplicaci贸n mediante el uso de un lenguaje com煤n entre el negocio (cliente) y el desarrollo del software (arquitecto/desarrollador). Esto va m谩s all谩 de simplemente estar concentrado en detalles t茅cnicos.

Su atenci贸n va completamente al problema relevante y ayuda a identificar una arquitectura para informar sobre las herramientas que se usar谩n en el desarrollo del software. Es una arquitectura con un lenguaje com煤n, no solo t茅cnico. Una arquitectura que todos puedan entender.

Patr贸n de arquitectura Dise帽o orientado al dominio
Gu铆a la aplicaci贸n y el dise帽o a trav茅s del uso del lenguaje com煤n entre el negocio y el desarrollo.
Buscar modularizar el sistema a trav茅s de contextos delimitados

No entend铆 la explicaci贸n, 驴En que casos necesito aplicar esto? 驴En todos? Y, con lo del lenguaje com煤n entre la aplicaci贸n y el negocio, 驴Se refiere a representar el funcionamiento del negocio con los diferentes componentes de la aplicaci贸n?

驴Saben si existe algun curso en cualquier lenguaje que profundice en dise帽o orientado al dominio?
Quisiera implementar este tipo de dise帽o en un proyecto personal pero aun no logro comprender como llevar esta teor铆a a c贸digo.

Las explicaciones muy buenas pero, no estar铆a mal que en los ejemplos fueran sobre algunas aplicaciones reales, y quiz谩 un poco m谩s a detalle de como se form贸 dicha aplicaci贸n con este patr贸n.

Saludos!!!

Arquitectura con N Capas orientada al dominio propuesta por microsoft en el libro: Gu铆a de Arquitectura de N-Capas orientada al Dominio con .NET 4.0

馃馃馃
Dise帽o orientado al dominio
Lo que hacemos es guiar nuestra aplicaci贸n y el dise帽o a trav茅s del uso del lenguaje com煤n entre el negocio y el desarrollo. El obtener ese lenguaje del negocio y el poder hacer aplicaciones que est茅n concentradas en eso mucho m谩s que lo que est谩n concentradas en detalles t茅cnicos. Va m谩s all谩 de una sola aplicaci贸n, nos dice que busquemos modularizar nuestro sistema a trav茅s de los bounded context, que tratan de encontrar d贸nde el lenguaje cambia de sentido.

El DDD m谩s que una arquitectura es una forma de dise帽ar (vaya la redundancia). Es complicado de entender, pero en esencia consiste en que separes los componentes/modulos de tu desarrollo de acuerdo a como lo hace tambi茅n el negocio que quieres modelar.
El ejemplo de los usuarios es el m谩s completo, pues para una secci贸n de la aplicaci贸n el usuario significa email y contrase帽a. En otro es comprador, proveedor, due帽o, etc.
La idea principal de usar DDD es dise帽ar la l贸gica de negocio de la aplicaci贸n completamente aislada de la l贸gica de la implementaci贸n. Por ejemplo, es irrelevante saber que se usar谩 JS o C# si ni siquiera saber que es lo que har谩s ni como lo har谩s

Este patr贸n es muy interesante ya que lleva un buen grado de coordinaci贸n, primero se separa el sistema en partes dentro de un contexto limitado y luego se las coordina.

Muy claras las explicaciones!

Mucha teor铆a pero nada de c贸digo ^^. 馃槮

Veo este patr贸n ciertamente conectado con la experiencia de usuario, cosa que est谩 siendo muy relevante en la actualidad.