Arquitecturas Capas

Desarrollo I
Tema: Arquitectura Capas
Docente: Mg. Mario Ruben Pérez Cargua

Contenido
Objetivo
● Introducción
Identificar los Patrones de
● Modelos de Arquitectura Capas
capas mas utilizados para la
● N- Capas
creación de Software
● Introducción
Desarrollo de Software I / Antecedentes
Tipos de Aplicaciones
• Aplicaciones para dispositivos móviles: Se trata de aplicaciones web con una interfaz
adaptada para dispositivos móviles o aplicaciones de usuario desarrolladas para el terminal.
• Aplicaciones de escritorio: Son las aplicaciones clásicas que se instalan en el equipo del
usuario que la vaya a utilizar.
• RIA (Rich Internet Applications): Se trata de aplicaciones que se ejecutan dentro del
navegador gracias a un plug-in y que ofrecen una mejor respuesta que las aplicaciones web
y una interfaz de calidad similar a las aplicaciones de usuario con la ventaja de que no hay
que instalarlas.
• Servicios: Se trata de aplicaciones que exponen una funcionalidad determinada en forma de

servicios web para que otras aplicaciones los consuman.
• Aplicaciones web: Son aplicaciones que se consumen mediante un navegador y que

ofrecen una interfaz de usuario estándar y completamente interoperable.
Arquitectura de la infraestructura
La topología de despliegue depende directamente de las restricciones impuestas por el cliente, de las
necesidades de seguridad del sistema y de la infraestructura disponible para desplegar el sistema.
• Despliegue distribuido
Permite separar las capas lógicas en distintos niveles físicos, Al mismo tiempo,
al separar las capas en distintos niveles aprovechamos mejor los recursos,
balanceando el número de equipos por nivel en función del consumo
La serialización de la información y su envío por la red tienen un coste no

despreciable. Así mismo, los sistemas distribuidos son más complejos y más
caros.
Arquitectura de la infraestructura
• Despliegue no distribuido.
Tiene la ventaja de ser más simple y más eficiente en las comunicaciones ya que las
llamadas son locales
Es más difícil permitir que varias aplicaciones utilicen la misma lógica de negocio al
mismo tiempo.
Los recursos de la máquina son compartidos por todas las capas

Arquitectura lógica
Para ello emplearemos en la medida de lo posible un conjunto de estilos arquitecturales conocidos.
Los estilos arquitecturales son “patrones” de nivel de aplicación que

definen un aspecto del sistema que estamos diseñando y representan
una forma estándar de definir o implementar dicho aspecto.
La diferencia entre un estilo arquitectural y un patrón de diseño es el nivel de abstracción, es

decir, un patrón de diseño da una especificación concreta de cómo organizar las clases y la
interacción entre objetos, mientras que un estilo arquitectural da una serie de indicaciones sobre
qué se debe y qué no se debe hacer en un determinado aspecto del sistema.
Arquitectura lógica
Implementación del diseño
Lo primero que tenemos que hacer es decidir qué tecnologías emplearemos. Por ejemplo, para
hacer una aplicación de escritorio escogeremos WPF, Windows Forms, o si nuestra aplicación
expone su funcionalidad como servicios web, usaremos WCF
• ¿Qué tecnologías ayudan a implementar los estilos arquitecturales

seleccionados?
• ¿Qué tecnologías ayudan a implementar el tipo de aplicación

seleccionada?
• ¿Qué tecnologías ayudan a cumplir con los requisitos no funcionales

especificados?
● Arquitectura en Capas
Arquitectura n-capas
La arquitectura en capas es una de las técnicas más

comunes que los Diseñadores/ Desarrolladores de
software utilizan para separar un sistema de
software muy complejo, principalmente para
aplicaciones empresariales. Esta separación se
conoce como LAYERING, que simplemente
significa descomponer un sistema de software en
sus partes, es decir, separar un sistema en capas
según preocupaciones y responsabilidades.
Arquitectura 3 capas
“Generalmente” existen 3 capas

principales de aplicación y una de
soporte, la capa de presentación, la
capa de Negocio o Dominio y la capa
de Acceso a datos o Persistencia,
donde cada capa descansa sobre otra,
la capa superior solo puede acceder
a la capa inferior y utilizar varios
servicios definidos, pero la capa
inferior no es consciente de la capa
superior, es decir: La capa inferior no
puede y no debería acceder a la capa
superior.
Capa de presentación o IU
Es responsable de manejar la interfaz gráfica de usuario como vistas renderizadas, archivos HTML de
una página web, la interfaz de línea de comandos o los formularios de una aplicación de escritorio. En esta
capa puedes aplicar patrones (Opcional) como
• Modelo vista controlador (MVC)

• Modelo jerárquico vista controlador (HMVC – PAC)
• Modelo vista presentador (MVP)
• Modelo vista – vista modelo (MVVM)
• Modelo vista presentador vista modelo
• Page controller
• Front controller
• Application controller
Todo lo que va ver el usuario, se puede crear

vista-controlador
Capa de negocio o domínio
Es el componente más importante, es el corazón de la aplicación, codifica las reglas comerciales

y el flujo de trabajo del mundo real, que determinan como se pueden crear, almacenar y cambiar los
datos de un objeto comercial. Las reglas comerciales describen las operaciones y restricciones que se
aplica a una organización.
La capa de dominio es muy compleja, es decir tiene un montón de métodos con lógica de negocio
podemos agregar la capa de servicio o aplicación, que es una capa delgada que sirve como
fachada y envuelve la capa de dominio, lo cual se encarga del flujo de operaciones, coordina
todas las transacciones.
Es el nivel central, pueden tener capaz dominio servicio o dominio dominio

Capa de negocio o domínio
En esta capa se puede usar patrones (Opcional) como
• Entidad de dominio, modelo de dominio u

objeto de negocio
• Objeto de valor
• Ruta agregada.
• Script de transacción
• Tabla modular
• El objeto de transferencia de datos
• Delegado de negocios
• Unidad de trabajo
Cada capa puede ser proyecto

Capa de acceso de datos o persistencia guardar el objeto que creamos en memoria a una base de datos
Se encarga de almacenar u obtener datos desde un almacén de datos, como una base de datos, un
servicio externo o un archivo plano. Esta capa también es conocida como capa de persistencia o capa de
integración, en ella podemos utilizar patrones (Opcional) como
• Enlace a datos de tabla La plantila es una clase

• Registro activo
Clase La clase nos sirve para crear un
• Mapeado de datos objeto
• Objeto de consulta
Clase Cliente {
• Objeto de acceso a datos }
• Repositorio Métodos para crear los objetos es un constructor
Cliente nuevo = new Client();
Un objeto ocupa un lugar en el espacio.

Arquitectura comportamiento
Bajo Acoplamiento
Arquitectura comportamiento (Presentación )
Patrones de
Arquitectura
Patrones de
Diseño
Arquitectura comportamiento (Negocio / Dominio)
Patrones de Diseño
Arquitectura comportamiento (Acceso a Datos)
Arquitectura comportamiento (Entidades)
Arquitectura comportamiento (Entidades)
● Arquitectura en el tiempo
Arquitectura Origen
Arquitectura Origen
Nivel: Es la separación física de la

aplicación
Capas: Es la separación lógica de

la aplicación
Arquitectura Origen
Arquitectura Origen
Arquitectura DDD
El diseño guiado por el dominio, en inglés: domain-driven design (DDD), es un enfoque para el
desarrollo de software con necesidades complejas mediante una profunda conexión entre la
implementación y los conceptos del modelo y núcleo del negocio
Arquitectura DDD
Principio de Inversión de Dependencia (DIP)
Este principio es una técnica básica, y será el que más presente tengas en el día a día si quieremos
hacer que tu código sea testable y mantenible. Gracias al principio de inversión de dependencias,
podemos hacer que el código que es el núcleo de nuestra aplicación no dependa de los detalles de
implementación, como pueden ser el framework que utilices, la base de datos, cómo te conectes
a tu servidor… Todos estos aspectos se especificarán mediante interfaces, y el núcleo no tendrá que
conocer cuál es la implementación real para funcionar.
A. Las clases de alto nivel no deberían depender de las clases de bajo nivel. Ambas deberían
depender de las abstracciones.
B. Las abstracciones no deberían depender de los detalles. Los detalles deberían depender de
las abstracciones.
Principio de Inversión de Dependencia (DIP)
Arquitectura
http://aitorrm.github.io/t%C3%A9cnicas%20y%20metodolog%C3%ADas/arquitectura_software_limpia/
● Arquitecturas Modernas
Desarrollo de Software I / Arquitecturas
Arquitectura Onion
• La aplicación está construida en
torno a un modelo de objetos
independiente.
• Las capas interiores definen las

interfaces. Las capas exteriores
implementan esas interfaces.
• La dirección del acoplamiento es

siempre hacia el centro.
• Todo el núcleo de código de la

aplicación se puede compilar y
ejecutar de forma aislada a la
infraestructura.
Bajo acoplamiento y mayor cohesión

Arquitectura Onion
Capa de entidades de dominio
Es la parte central de la arquitectura. Contiene todos los objetos del dominio de la aplicación. Si una
aplicación se desarrolla con el marco de la entidad ORM, esta capa contiene clases POCO (Code
First) o Edmx (Database First) con entidades. Estas entidades de dominio no tienen dependencias.
Capa de repositorio
La capa está destinada a crear una capa de abstracción entre la capa de entidades de dominio y la
capa de lógica empresarial de una aplicación. Es un patrón de acceso a datos que solicita un
enfoque de acceso a datos más débilmente acoplado. Creamos un repositorio genérico, que
consulta la fuente de datos para los datos, mapea los datos de la fuente de datos a una entidad
comercial y persiste los cambios en la entidad comercial a la fuente de datos.
Arquitectura Onion
Capa de servicio
La capa contiene interfaces que se utilizan para comunicarse entre la capa de interfaz de usuario y la capa
de repositorio. Contiene lógica empresarial para una entidad, por lo que también se denomina capa de
lógica empresarial.
Capa de interfaz de usuario
Es la capa más externa. Podría ser la aplicación web, la API web o el proyecto de prueba unitaria. Esta
capa tiene una implementación del principio de inversión de dependencias para que la aplicación
construya una aplicación débilmente acoplada. Se comunica con la capa interna a través de interfaces.
Arquitectura Onion (Cebolla)
Datos OA.- Es un proyecto de biblioteca de clases. Contiene clases de POCO junto con
clases de configuración. Representa la capa de entidades de dominio de la arquitectura de
cebolla. Estas clases se utilizan para crear tablas de bases de datos. Es una parte central y
central de la aplicación.
OA.Repo.- Es un proyecto de biblioteca de segunda clase. Tiene una clase de repositorio

genérico con su implementación de interfaz. También contiene una clase DbContext. El
enfoque de acceso a datos de Entity Framework Code First necesita crear una clase de
contexto de acceso a datos que herede de la clase DbContext. Este proyecto representa la
capa de repositorio de la arquitectura de cebolla.
Servicio de OA.- Es un proyecto de biblioteca de tercera clase. Contiene interfaces y lógica

empresarial. Estas interfaces se comunican entre la interfaz de usuario y la lógica de acceso
a datos. A medida que se comunica a través de interfaces, crea aplicaciones que están
acopladas de manera flexible. Este proyecto representa la capa de servicio de la arquitectura
de cebolla.
OA.Web.- Es una aplicación web ASP.NET Core en este ejemplo, pero podría ser un
proyecto de prueba unitaria o API web. Es la parte más externa de una aplicación mediante
la cual el usuario final puede interactuar con la aplicación. Compila aplicaciones poco
acopladas con inyección de dependencia incorporada en ASP.NET Core. Representa la capa
de interfaz de usuario de la arquitectura de cebolla.
Arquitectura Clear (Limpia)
• La aplicación no debe depender

de la interfaz de usuario, es decir
que nuestra interfaz debería ser
intercambiable (Windows, web,
móvil, etc.)
• La aplicación no debe depender

de la base de datos (Oracle, sql
server, mongo, etc.)
• Todas las capas deben poder

probarse en forma independiente.
• No se debe depender de
frameworks específicos, legacy
systems, etc.
• Entidades: Corresponden a los objetos de negocios. Aquí encontramos objetos que contienen, datos,
conducta y reglas de negocio. El modelado de esta capa normalmente se hace basado en los
principios de modelado de DDD.
• Casos de Uso: aquí se orquesta la funcionalidad de la aplicación, por ejemplo “Registrarse para un
curso”, esto implicará una serie de pasos que utilizarán las entidades para hacer las operaciones y
pasará información los adaptadores .
• Adaptadores: En el circulo preparamos los datos para que puedan ser utilizados por las capas mas
externas, por ejemplo podríamos enviar Json para un servicio web, aquí estarían los presentadores en
un patrón MVP, o vistas y controladores de un patrón MVC. También aquí prepararíamos los datos
para ser grabados en una fuente de datos.
• La capa externa: Aquí está la base de datos, el servicio al que alimentamos datos, el navegador, etc.
Arquitectura Proyecto
La empresa “TécniCar”, dedicada al mantenimiento preventivo, correctivo vehículos multi-marca, nos ha

solicitado crear el Módulo de Ingreso a Taller, Se ha considerado las siguientes Entidades Básicas
Que vamos ha realizar
• Aplicación taller mecánico entorno Windows

• Formularios Modernos
• CRUD para ejemplificar los conceptos
• Programación orientada a objetos (POO)
• Base de datos SQLServer
• Arquitectura en capas DDD + DIP
• EntityFramework – dataFirst
• C#
Como lo vamos ha realizar
• Arquitectura en Capas DDD+DIP
• Estratificación Flexible
Dependencia
1. Presentación depende
* Aplicación
* Dominio
2. Aplicación depende
* Dominio
* Infraestructura
3. Infraestructura depende
* Dominio
Dominio No Tiene Dependencia

1.InterfazUsuario 2.Aplicación 3.Dominio 4.Infraestuctura
UI.windows CrossCuting
Aplicación Modelos
Acceso Datos
Aplicación DTO Servicios
Servicios Email
Servicios Externo
windows Aplicación Modelos Acceso Datos
• Formularios • Clase Servicio • Entidades • Repositorio

• Vista Modelos Entidad • Objeto Valores
• Controladores • Abstracciones
App
Crear Arquitectura
Crear Arquitectura
1.- UserInterfaz : se encargará de la UI de usuario sea esta web / escritorio / móvil / servicios web
• AplicationController: Contiene todo el controlador de la

forma, la lógica de la forma y validación de interfaz
• Form: Contiene las formas del sistema, para este caso

windowsform
• ViewModel: Contiene las entidades de vista

Crear Arquitectura..
• Aplication: Capa intermedia que sirve como enlace de los servicios, utilizada en aplicaciones con
lógica de negocio complejas
• DTO: Capa que se utiliza para los objetos DTO se

se aplica en la arquitectura, El patrón DTO tiene
como finalidad de crear un objeto plano (POJO)
con una serie de atributos que puedan ser enviados
o recuperados del servidor en una sola invocación,
de tal forma que un DTO puede contener
información de múltiples fuentes o tablas y
concentrarlas en una única clase simple.
Crear Arquitectura…
La capa de dominio se creará dos proyectos:
• El Modelo
• Servicio
• Domain.Model: En él se describen las distintas entidades, sus atributos, papeles y relaciones
• Abstractions: donde se crean las interfaces que se

implementarán en la capa de infraestructura
• Entidades: Clases POJO que hacen referencia a las
tablas de BD (mapeo)
• ObjectValues: Un Value Object se usa para modelar

conceptos de nuestro sistema, como pueden ser
identificadores, fechas o rangos de fechas, precios,
pesos, velocidades (prácticamente cualquier
magnitud es modelable como VO)
• Domain.Services: En DDD, un Servicio de dominio es un tipo específico de clase de capa de dominio

que usamos cuando queremos poner alguna lógica de dominio que se base en dos o más entidades.
Usamos los Servicios de dominio cuando poner la lógica en una entidad en particular rompería la
encapsulación y requeriría que la entidad sepa cosas que realmente no deberían preocuparle.
La capa de Infraestructura se creará tres proyectos:
• DataAcess
• EmailServices
• ExternalServices
• DataAcess: En esta capa se crearán las operaciones de BD (SQL)

• EmailServices: En las capas de infraestructura transversal también existe el concepto de Servicios.

Se encargarán de agrupar acciones de infraestructura, como mandar e-mails, controlar aspectos de
seguridad, gestión de operaciones, logging, etc. Así pues, estos Servicios, agrupan cualquier tipo de
actividad de infraestructura transversal ligada a tecnologías específicas.
• ExternalServices. Son objetos que manejan las semánticas específicas de la comunicación con
servicios externos (servicios web normalmente), de forma que aíslan a nuestra aplicación de las
idiosincrasias de llamar a diferentes servicios y proporcionar servicios adicionales como mapeos
básicos entre el formato expuesto por los tipos de datos esperados por los servicios externos y el
formato de datos que nosotros utilizamos en nuestra aplicación.
Gracias
Responsabilidad con pensamiento positivo

Tareas
● Realizar una investigación sobre las Buenas Prácticas del desarrollo de
Software para .net con C#
● Crear Arquitectura implementada con proyectos independientes en
función del proyecto integrador de carrera.
NOTA: El deber será enviado en formato rar, especificando su nombre y número de semana.
Ejemplo: Semana1_Mario_Pérez.rar

Arquitecturas Capas

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Arquitecturas Capas

Cargado por

Copyright:

Formatos disponibles

Desarrollo I

Tema: Arquitectura Capas

Docente: Mg. Mario Ruben Pérez Cargua

• Servicios: Se trata de aplicaciones que exponen una funcionalidad determinada en forma de

• Aplicaciones web: Son aplicaciones que se consumen mediante un navegador y que

La serialización de la información y su envío por la red tienen un coste no

Los recursos de la máquina son compartidos por todas las capas

Para ello emplearemos en la medida de lo posible un conjunto de estilos arquitecturales conocidos.

Los estilos arquitecturales son “patrones” de nivel de aplicación que

La diferencia entre un estilo arquitectural y un patrón de diseño es el nivel de abstracción, es

• ¿Qué tecnologías ayudan a implementar los estilos arquitecturales

• ¿Qué tecnologías ayudan a implementar el tipo de aplicación

• ¿Qué tecnologías ayudan a cumplir con los requisitos no funcionales

La arquitectura en capas es una de las técnicas más

“Generalmente” existen 3 capas

• Modelo vista controlador (MVC)

Todo lo que va ver el usuario, se puede crear

Es el componente más importante, es el corazón de la aplicación, codifica las reglas comerciales

Es el nivel central, pueden tener capaz dominio servicio o dominio dominio

• Entidad de dominio, modelo de dominio u

Cada capa puede ser proyecto

• Enlace a datos de tabla La plantila es una clase

Cliente nuevo = new Client();

Un objeto ocupa un lugar en el espacio.

Nivel: Es la separación física de la

Capas: Es la separación lógica de

• Las capas interiores definen las

• La dirección del acoplamiento es

• Todo el núcleo de código de la

Bajo acoplamiento y mayor cohesión

Capa de interfaz de usuario

OA.Repo.- Es un proyecto de biblioteca de segunda clase. Tiene una clase de repositorio

Servicio de OA.- Es un proyecto de biblioteca de tercera clase. Contiene interfaces y lógica

• La aplicación no debe depender

• La aplicación no debe depender

• Todas las capas deben poder

La empresa “TécniCar”, dedicada al mantenimiento preventivo, correctivo vehículos multi-marca, nos ha

Que vamos ha realizar

• Aplicación taller mecánico entorno Windows

Dominio No Tiene Dependencia

1.InterfazUsuario 2.Aplicación 3.Dominio 4.Infraestuctura

windows Aplicación Modelos Acceso Datos

• Formularios • Clase Servicio • Entidades • Repositorio

• AplicationController: Contiene todo el controlador de la

• Form: Contiene las formas del sistema, para este caso

• ViewModel: Contiene las entidades de vista

• DTO: Capa que se utiliza para los objetos DTO se

• Domain.Model: En él se describen las distintas entidades, sus atributos, papeles y relaciones

• Abstractions: donde se crean las interfaces que se

• ObjectValues: Un Value Object se usa para modelar

• Domain.Services: En DDD, un Servicio de dominio es un tipo específico de clase de capa de dominio

• DataAcess: En esta capa se crearán las operaciones de BD (SQL)

• EmailServices: En las capas de infraestructura transversal también existe el concepto de Servicios.

Responsabilidad con pensamiento positivo

También podría gustarte