Contenido

1.

Arquitectura de software......................................................................3

1.1.

Conceptos fundamentales.................................................................3

Estilos................................................................................................... 3

Lenguajes de descripcin arquitectnica (ADLs)...................................4

2.

La arquitectura de software..................................................................4

2.1 Componentes e interacciones...............................................................4

2.1.1. Componentes.................................................................................... 4
2.1.2. Interacciones..................................................................................... 5
3.

Caractersticas...................................................................................... 5

4.

Tipos de arquitecturas..........................................................................5

Monoltica.................................................................................................... 5
Cliente-servidor........................................................................................... 5
Arquitectura de tres niveles........................................................................5
5.

Modelos de la arquitectura de software................................................6

Modelos estructurales...........................................................................6

Modelos dinmicos............................................................................... 6

Modelos de proceso.............................................................................. 6

6.

El Rol del Arquitecto de Software:.........................................................7

6.1.

Actividades del arquitecto.................................................................7

6.1.1.

Concepcin del proyecto................................................................7

6.1.2.

Requerimientos.............................................................................. 7

6.1.3.

Diseo del sistema.........................................................................8

6.1.4.

Construccin y pruebas del sistema...............................................8

6.1.5.

Liberacin....................................................................................... 9

6.1.
7.
7.1.

Categoras de arquitectos..................................................................9
Arquitectura DDD.................................................................................. 9
Qu es el dominio?...........................................................................9

8.

Qu es SignalR?................................................................................ 10

9.

Node.js................................................................................................ 19

10.

Anexo............................................................................................... 20

11.

Bibliografa...................................................................................... 21

https://prezi.com/2uraxobilh0t/tipos-de-arquitecturas-de-software/.........21
http://xurxodeveloper.blogspot.pe/20114/01/ddd-la-logica-de-dominio-esel-corazon.html......................................................................................... 21
https://prezi.com/g_k6fdrg_rmd/arquitectura-ddd-net/..............................22

http://es.slideshare.net/lilyPacheco7/arquitectura-de-software-1392522622
https://es.wikipedia.org/wiki/Node.js.........................................................22

1.

Arquitectura de software.

1.1.

Conceptos fundamentales

Una arquitectura de software para un sistema es la estructura o

estructuras del sistema, que consisten en elementos, sus propiedades
externamente visibles y las relaciones entre ellas.
-

Estilos

Un estilo, es un concepto descriptivo que define una forma de

articulacin u organizacin arquitectnica. El conjunto de los estilos
cataloga las formas bsicas posibles de estructuras de software,
siendo este, un aspecto fundamental de la AS (Wolfy Perry).
- El modelado OO y UML no lo cubren satisfactoriamente.
- Su descripcin, se puede formular en lenguaje natural o en
-

diagramas
Se recomienda hacerlo en un lenguaje de descripcin

arquitectnica (ADLs) o en lenguajes formales de especificacin.

Ejemplos:
Arquitecturas basadas en flujo de datos, las peer-to-peer, las de
invocacin implcita, las jerrquicas, las centradas en datos o las
de intrprete- mquina virtual.
-

Lenguajes de descripcin arquitectnica (ADLs)

Los ADLs permiten modelar una arquitectura mucho antes que se lleve
a cabo la programacin de las aplicaciones que la componen, analizar

su adecuacin, determinar sus puntos crticos y eventualmente simular

su comportamiento.
Aparecieron a principios de los 90s
Lo integran un conjunto de propuestas, ampliamente conocidas en
.

2.

el mbito acadmico
Se fundamentan en la incapacidad de expresar conectores en UML
Alrededor de 20 ADLs han sido reconocidos
Son poco utilizados en la industria del software
Ejemplos: AADL, Acme, Rapide, LILEANA, etc.

La arquitectura de software

Es un conjunto de patrones que proporcionan un marco de referencia

necesario para guiar la construccin de un software, permitiendo a
los programadores, analistas y todo el conjunto de desarrolladores
del software compartir una misma lnea de trabajo y cubrir todos los
objetivos y restricciones de la aplicacin. Es considerada el nivel ms alto en
el diseo de la arquitectura de un sistema puesto que establecen la
estructura, funcionamiento e interaccin entre las partes del software.
2.1 Componentes e interacciones
2.1.1. Componentes

La arquitectura de software se compone por:

clientes y servidores.

bases de datos.

filtos.

niveles en sistemas jerrquico.

2.1.2. Interacciones

Entre los componentes de la arquitectura de software existe un conjunto de

interacciones entre las que sobresalen:

llamadas a procedimientos.

comportamiento de variables.

protocolos cliente servidor.

transmisin asncrona de eventos.

3.

Caractersticas

La arquitectura de software forma la columna vertebral para construir un

sistema de software, es en gran medida responsable de permitir o no ciertos
atributos de calidad del sistema entre los que se destacan la confiabilidad y el
rendimiento del software. Adems es un modelo abstracto reutilizable que
puede transferirse de un sistema a otro y que representa un medio de
comunicacin y discusin entre participantes del proyecto, permitiendo as la
interaccin e intercambio entre los desarrolladores con el objetivo final de
establecer el intercambio de conocimientos y puntos de vista entre ellos.

4.

Tipos de arquitecturas
Monoltica
Donde el software se estructura en grupos funcionales muy acoplados.
Cliente-servidor
Donde el software reparte su carga de cmputo en dos partes
independientes pero sin reparto claro de funciones.
Arquitectura de tres niveles
Especializacin de la arquitectura cliente- servidor donde la carga se
divide en tres partes (o capas) con un reparto claro de funciones:
una capa para la presentacin (interfaz de usuario),
otra para el clculo (donde se encuentra modelado el negocio) y
otra para el almacenamiento (persistencia).

5.

Modelos de la arquitectura de software

La arquitectura de software cuenta con varios modelos, ellos son:

Modelos estructurales

Son similares a la vista estructural, pero su nfasis primario radica en la

(usualmente una sola) estructura coherente del sistema completo, en vez de
concentrarse en su composicin. Los modelos de framework a menudo se
refieren a dominios o clases de problemas especficos. El trabajo que
ejemplifica esta variante incluye arquitecturas de software especficas de
dominios, como CORBA, o modelos basados en CORBA, o repositorios de
componentes especficos, como PRISM.

Modelos dinmicos

Enfatizan la cualidad conductual de los sistemas, Dinmico puede referirse a

los cambios en la configuracin del sistema, o a la dinmica involucrada en el
progreso de la computacin, tales como valores cambiantes de datos.

Modelos de proceso

Se concentran en la construccin de la arquitectura, y en los pasos o procesos

involucrados en esa construccin. En esta perspectiva, la arquitectura es el
resultado de seguir un argumento (script) de proceso. Esta vista se ejemplifica
con el actual trabajo sobre programacin de procesos para derivar
arquitecturas.

6.

El Rol del Arquitecto de Software:

A lo largo de las distintas entregas de esta columna hemos cubierto las

actividades del ciclo de desarrollo de la arquitectura de software y su
integracin dentro del ciclo de desarrollo de software. En todas estas
actividades, hay un rol especfico que juega un papel preponderante y es el
del arquitecto de software. Mucho ha sido escrito en relacin con este rol,
sin embargo, en esta columna hablaremos al respecto enfocndonos ms
bien en las actividades que debe realizar el arquitecto a lo largo del ciclo de
desarrollo, particularmente en el contexto de desarrollos de software a la
medida.
6.1.

Actividades del arquitecto

6.1.1. Concepcin del proyecto.

Un proyecto de desarrollo de software, particularmente
cuando se trata de un desarrollo a la medida, inicia
generalmente por una etapa en la cual se debe de generar
una propuesta tcnica y econmica, muchas veces en un
periodo corto de tiempo. En sta etapa, el arquitecto juega un
papel muy importante pues en general en l recae la
responsabilidad de realizar una traduccin de las necesidades
que expresa un cliente hacia una solucin tcnica preliminar,
que es una pieza clave para producir una estimacin del
esfuerzo necesario para realizar el desarrollo. El arquitecto
puede, de hecho, tambin participar en el trabajo de
estimacin del sistema. Durante esta etapa del proyecto, el
arquitecto debe hacer uso de habilidades tcnicas (duras) y
no-tcnicas (suaves). Como parte de las habilidades
tcnicas, debe poder identificar estilos arquitectnicos y
tecnologas que sean apropiados para resolver el problema y
proponer una solucin preliminar. Como parte de las
habilidades no-tcnicas, debe ser capaz de realizar un anlisis
de las necesidades del cliente, especialmente desde una
perspectiva de negocio y poder explicar la solucin tcnica
que propone a los distintos involucrados del proyecto.

6.1.2.

Requerimientos.

Durante la fase de requerimientos, el arquitecto de software

se involucra con los requerimientos que influyen en la
arquitectura (drivers) y particularmente con respecto a los
atributos de calidad del sistema. El arquitecto debe
preocuparse por que se identifiquen atributos de calidad
pertinentes para el sistema (alineados a los objetivos de

negocio) y que las mtricas asociadas estn justificadas. En

caso de que el cliente solicite atributos de calidad con
mtricas muy demandantes (por ejemplo una disponibilidad
del 99.99%) debe ser capaz de entender la justificacin de
esas mtricas y, en caso necesario, debe poder negociar con
el cliente para establecer mtricas adecuadas. Nuevamente,
el arquitecto debe emplear aqu una combinacin de
habilidades duras y suaves con el fin de lograr una
identificacin adecuada de los requerimientos que influirn
sobre el diseo arquitectnico.

6.1.3. Diseo del sistema.

La etapa de diseo del sistema es aquella donde el arquitecto
de software juega el papel principal, particularmente al
momento de disear la arquitectura. Aqu el arquitecto debe
hacer uso de todas sus habilidades tcnicas con el fin de
establecer una solucin tcnica pertinente que satisfaga, en
la medida de lo posible, los requerimientos que influyen en la
arquitectura
Durante la etapa de diseo, el arquitecto debe tambin hacer
uso de muchas habilidades no-tcnicas. La comunicacin
durante esta etapa es fundamental, ya que el arquitecto debe
ser capaz de comunicar el diseo, y las decisiones que lo
llevaron al mismo, ya sea de forma escrita, como parte de la
documentacin de la arquitectura, o bien de forma oral al
explicar el diseo de la arquitectura al equipo de desarrollo.
Durante la evaluacin del diseo de la arquitectura, el
arquitecto debe ser capaz de presentar el contexto del
problema y el diseo de la arquitectura al comit de
evaluacin, y debe ser capaz de responder a las preguntas de
dicho comit, o bien de aceptar las observaciones que se
hacen al diseo.

6.1.4. Construccin y pruebas del sistema.

Durante de la construccin del sistema, el esfuerzo tcnico del
arquitecto disminuye, aunque esto no significa que ya no se
realizan actividades tcnicas. En esta etapa, desde un punto de
vista tcnico, el arquitecto debe terminar de completar las
partes faltantes del diseo de la arquitectura y corregir las
decisiones previas que hayan resultado ser equivocadas. Desde
un punto de vista no-tcnico, el esfuerzo aumenta pues el
arquitecto debe enfocarse en cuidar que el sistema se
desarrolle de acuerdo a la arquitectura que se defini para el
mismo. Aqu el arquitecto juega un papel de mentor y muchas
veces debe explicar cuestiones del diseo del sistema al equipo
de desarrollo. El arquitecto puede tambin realizar actividades

de aseguramiento de calidad tales como inspecciones de

productos de trabajo, ya que su nivel tcnico y conocimiento
del dominio del problema le da una ventaja para identificar
problemas que posiblemente podran no ser identificados por
ingenieros con un nivel tcnico y conocimiento del dominio del
problema menores. Al momento de realizar pruebas del
sistema, la participacin del arquitecto es importante,
particularmente al momento de realizar pruebas relativas a los
atributos de calidad del sistema.

6.1.5.

Liberacin.

Al momento de implantar el sistema en el ambiente productivo,

muchas veces es necesario realizar ajustes finos sobre el
sistema, en particular una vez que el sistema ya est operando
en el ambiente de uso definitivo. La participacin del arquitecto
puede estar enfocada a realizar ajustes finos de la aplicacin
con el fin de lograr un funcionamiento ptimo de la misma.

6.1. Categoras de arquitectos

Dependiendo del tamao del sistema, es posible que no haya un solo
arquitecto que participe a lo largo de todo el proyecto y que, ms bien,
existan distintos arquitectos especializados que intervienen a distintos
momentos del desarrollo. As, frecuentemente, el arquitecto que participa
en la concepcin de un proyecto es conocido como el Arquitecto de
Soluciones mientras que el arquitecto que participa durante el desarrollo es
conocido como el Arquitecto de Software. Pueden haber otras
especializaciones tales como el Arquitecto de Sistemas, que se encarga de
tomar decisiones de diseo que van ms all del software y que involucran
hardware, o bien el Arquitecto Empresarial que, como su nombre indica,
se especializa en el diseo de una arquitectura empresarial. Existen tambin
ciertas especializaciones a nivel tecnolgico, como por ejemplo el
Arquitecto SOA. Cualquiera que sea la especialidad del arquitecto, en
general, un aspecto comn es que su rol involucra la toma de decisiones
que tienen un fuerte impacto sobre el sistema.

7.

Arquitectura DDD

En una aplicacin donde el diseo est orientado al dominio (Domain design

Driven o DDD), trmino que introdujo Eric Evans en su libro, el dominio debe
ser lo ms importante de una aplicacin, es su corazn.

7.1.Qu

es

el

dominio?

El dominio es modelo de una aplicacin y su comportamiento, donde

se definen los procesos y la reglas de negocio al que est enfocada
la aplicacin, es la funcionalidad que se puede hablar con un experto
del negocio o analista funcional, esta lgica no depende de ninguna
tecnologa como por ejemplo si los datos se persisten en una base de
datos, si esta base de datos es SQL Server, Neo4j, MongoDB o la que
sea y lo que es ms importante, esta lgica no debe ser reescrita o
modificada porque se cambie una tecnologa especfica en una
aplicacin.
En un diseo orientado al dominio lo dependiente de la tecnologa
reside en el exterior como si capas de una cebolla fueran, donde
podemos sustituir una capa por otra utilizando otra tecnologa y la
funcionalidad de la aplicacin no se ve comprometida.
La arquitectura en capas es una buena forma de representar un
diseo orientado al dominio, abstrayendo cada capa mediante
interfaces, de forma que no haya referencias directas entre la
implementacin real de las capas, lo que nos va a permitir
reemplazar capas en el futuro de una forma ms segura y menos
traumtica.
En una arquitectura en capas el dominio reside en la capa ms
profunda o core, donde no depende de ninguna otra.
Ejemplo

de

dominio

Veamos unos ejemplos de requisitos y que objetos podramos

identificar
pertenecientes
al
dominio.
En la web para poder registrar un usuario es necesario tener unos
valores del usuario cumplimentados como pueden ser el nombre de
usuario,email
y
contrasea
Este requisito podemos intuir que debe de existir un objeto usuario,
seguramente una entidad, que mnimo va a tener 3 atributos,
nombre de usuario, email y contrasea. La validacin de los campos
obligatorios debe residir en la propia entidad para evitar
tener Anemic Domain Model, que es tener entidades sin
comportamiento. La validacin de campos obligatorios de una
entidad es el comportamiento bsico que una entidad puede tener,
de no hacerlo la entidad, que tiene toda la informacin para poder
hacerlo que son sus atributos, estaramos delegando esta validacin
exclusivamente en el cliente consumidor de esta entidad como
puede ser por ejemplo un cliente javascript, si ms adelante nuestra
aplicacin evoluciona a publicar una Api para que otras aplicaciones
puedan registrar usuarios mediante esta API, estaramos forzando a
que estos clientes realicen la validacin de campos obligatorios, o lo

que

es

peor,

podra

no

existir

esta

validacin.

Esta entidad usuario es un ejemplo de modelo de dominio que

adems tiene comportamiento o reglas de negocio como es la
validacin
de
un
usuario
para
poder
darse
de
alta.

8.

Qu es SignalR?

SignalR es una librera creada para desarrolladores de ASP.NET que facilita el

proceso de aadir funcionalidades en tiempo real a aplicaciones web, es decir,
la capacidad del servidor de enviar informacin al cliente sin tener que esperar
a que el cliente realice una peticin.

Ejemplos de aplicaciones web en tiempo real pueden ser chats, monitorizacin,

aplicaciones
colaborativas
o
incluso
juegos.

SignalR ofrece una API para crear llamadas remotas (RPC) desde el servidor a
funciones Javascript existentes en el cliente. No tenemos que encargarnos de
gestionar la conexin, ya que SignalR lo hace automticamente. Podemos
enviar mensajes a un cliente especfico o a todos los conectados al servidor.
SignalR se basar en Websocket cuando est disponible. Cuando no sea el
caso, utilizar otra tecnologa disponible para funcionalidades en tiempo real,
como puede ser Server Sent Requests, Forever Frame o Ajax long polling. En
funcin del navegador en el que se ejecute la aplicacin, se escoger un
mtodo de transporte u otro, pero es un proceso totalmente transparente para
nosotros, sin que sea necesario tener conocimientos de estos transportes ni de
cmo debemos implementar nuestro cdigo en funcin del navegador que
utilicemos.
Para implementar una aplicacin SignalR tendremos lo que denominamos un
Hub y un Hub proxy.

Un Hub/Hub proxy no es ms que un medio que permite al cliente realizar

llamadas a mtodos servidor y viceversa, como si esos mtodos se estuvieran
llamando en local.
El Hub estar en la parte del servidor, y expondr los mtodos disponibles al
cliente. El Hub proxy estar en el lado del cliente, y expondr los mtodos
disponibles al servidor.
Nada mejor que ponerse manos a la obra para aprender y ver cmo funcionan
las cosas, as que vamos a ello.
Vamos a realizar una pequea aplicacin que consistir en un chat. Segn
entren usuarios, se les ir pidiendo su nombre de usuario y podrn chatear en
una sala habilitada para todos.
Vamos a crear un proyecto web nuevo, de ASP.NET escogiendo la plantilla
vaca.

Una vez lo tengamos, tendremos que aadir las libreras necesarias para
utilizar SignalR. Para ello, hacemos click derecho en el proyecto, le damos a

Manage Nuget Packages, buscamos SignalR e instalamos

paquete Microsoft.AspNet.SignalR, tal como se indica en la imagen.

el

Una vez hecho esto, vamos a comenzar a crear la parte del servidor.
Lo primero que tendremos que hacer es registrar la ruta que los clientes
utilizarn para conectarse al Hub, que por defecto ser /signalr (puede
cambiarse si fuese necesario). Esto se hace en el fichero Startup.cs (si al crear
el proyecto no se ha generado ninguno, cralo manualmente). Dentro de la
clase Startup, llamaremos a MapSignalR para registrar dicha ruta. El cdigo
nos debe quedar como podemos ver en la siguiente imagen.

Tras ello crearemos el Hub en s.

Creamos una carpeta llamada Hubs y dentro creamos una clase ChatHub, con
el siguiente cdigo:

Como vemos, la clase hereda de Hub, y podemos empezar a aadirle mtodos

que podrn ser llamados desde el lado del cliente. Todos los mtodos deben
ser pblicos y pueden retornar valores que llegarn al cliente en formato JSON.
Vamos desglosar aqu el cdigo que hemos puesto en la clase para ver qu
realizan.

En primer lugar, tenemos un listado para almacenar los usuarios que se van a ir
conectando. De cada uno almacenaremos su nombre de usuario y su ID de
conexin.
A continuacin, nos encontramos con los mtodos que expone el
Hub. Connect y Send se llamarn para almacenar los usuarios que se vayan
agregando y para mandar mensajes a todas las personas conectadas
respectivamente.
Por otro lado, el mtodo onDisconnected() es una sobrecarga de uno de los
tres mtodos que ofrece la clase Hub para controlar el ciclo de vida de
conexin y saber cundo un usuario se ha conectado, desconectado o
reconectado tras una prdida temporal de la conexin, que son los siguientes:

OnConnected()

Se llamar cuando un cliente al Hub. Tras ejecutar el cdigo que pongamos en

este mtodo, se llamar al callback start().done en el cliente.

OnDisconnected()

Se llamar automticamente cuando un cliente se desconecte del Hub.

OnReconnected()

Se llamar cuando tras un periodo de desconexin, el cliente se ha podido

reconectar al Hub (como por ejemplo una cada corta de la conexin a
Internet).
Nosotros hemos implementado el mtodo onDisconnected(), para actualizar la
lista de usuarios que estn conectados al chat cuando alguien se desconecte.
Quizs te preguntes por qu no hemos implementado OnConnected() en vez
de usar Connect(). Es simplemente por la razn de que queremos almacenar el
nombre de usuario de la persona que se conecte al Hub, cosa que no
podramos hacer con el mtodo onConnected().
Si echamos un vistazo al mtodo Connect():

Lo que hacemos es almacenar el nomre de usuario de la persona que se ha

conectado, el identificador de su conexin (que lo obtenemos
mediante Context.ConnectionId), y posteriormente hacemos una llamada a un
mtodo del cliente.
Para realizar llamadas a los mtodos de los clientes conectados a este hub, lo
haremos el objeto Clients. A partir de aqu, podremos realizar acciones a todos
los conectados (mediante Clients.All), al que ha realizado la peticin al servidor
(mediante Clients.Caller), a todos excepto el que ha hecho la peticin
(mediante Clients.Others) hay muchas combinaciones existentes. De hecho,
podemos hasta crear grupos determinados de usuarios para llamar slo a un
nmero determinado. Podemos ver todas las formas de llamar a clientes
en este enlace.
Tras elegir a quin queremos llamar, escribiremos qu mtodo queremos
llamar. Para ello, simplemente escribiremos el nombre del mtodo y pasamos
los parmetros necesarios. En nuestro caso, el mtodo que definiremos en el
cliente es updateUsers y recibir la lista de usuarios conectados y el nmero
actual. IntelliSense no nos dar sugerencias, ya que no conoce qu mtodos
se han definido en el cliente (puesto que estos estarn definido en Javascript).
Cuando tenemos definidos los mtodos del servidor, es hora de pasar al
cliente. Nuestro cdigo es el siguiente:

Hemos marcado aquellos mtodos que tienen que ver con SignalR.
En primer lugar, debemos comentar que SignalR genera un proxy
automticamente. Esto nos permite simplificar el cdigo que tenemos que
implementar, pero podramos utilizar igualmente SignalR sin proxy. Nosotros
optamos por hacerlo ya que la sintaxis es mucho ms clara.
Lo que hacemos en primer lugar es obtener la referencia al Hub,
mediante $.connection.chatHub. Cabe destacar que el nombre del Hub debe
ser el mismo que hemos creado en el lado del servidor, salvo que utilizamos
lowerCamelCase para el nombre.
A continuacin, definimos los mtodos que tendr el cliente y que podrn ser
llamados
desde
el
servidor.
Para
ello,
se
aaden
mediante ref.client.nombreMetodo, donde ref es la referencia al hub
anteriormente obtenida. En nuestro caso hemos definido dos
mtodos, updateUsers y broadcastMessage, que se encargar de mostrar en
pantalla el mensaje que nos mande el servidor.
Por ltimo, para iniciar la conexin con el Hub, lo hacemos
mediante $.connection.hub.start(). Adems de ello, podemos especificar una
funcin callback para que cuando se realice la conexin, se ejecute. Se hace
mediante done, y en nuestro caso lo que hacemos cuando se establezca la
conexin correctamente es llamar al mtodo Connect() del servidor para que
este almacene nuestro nombre de usuario. Como podis ver, las llamadas a
mtodos del servidor se hacen mediante ref.server.metodo, con el nombre del
mtodo en lowerCamelCase (fijaos que pone send y no Send).
Para que SignalR funcione correctamente tendremos que importar los scripts
correspondientes en el fichero HTML, que son los que se indican en la imagen
(y en dicho orden!).

El script signalr/hubs hace referencia al proxy se genera automticamente y

no existe fsicamente, pero debemos incluirlo si queremos utilizar la sintaxis
que comentamos anteriormente.
Adems de estos ficheros incluiremos los scripts necesarios para ejecutar
nuestro programa.
Tras ello, si ejecutamos la aplicacin:

Aparecer nuestro chat con el nombre de usuario que nos ha pedido. Si ahora
probamos a abrir otra ventana del navegador y abrimos la aplicacin, al
conectarnos veremos cmo se actualiza la lista de usuarios conectados de
ambos navegadores automticamente.

9.

Node.js

Es un entorno en tiempo de ejecucin multiplataforma, de cdigo abierto,

para la capa del servidor basado en el lenguaje de
programacin ECMAScript, asncrono, con I/O de datos en una arquitectura
orientada a eventos y basado en el motor V8 de Google. Fue creado con el

enfoque de ser til en la creacin de programas de red altamente

escalables, como por ejemplo:
Servidores web. Fue creado por Ryan Dahl en 2009 y su evolucin est
apadrinada por la empresa Joyent, que adems tiene contratado a Dahl en
plantilla.
Node.js es similar en su propsito a Twisted o Tornado de Python, Perl Object
Environment de Perl, libevent o libev
de C, EventMachine de Ruby, vibe.d de D y JEE de Java existe Apache
MINA, Netty, Akka, Vert.x, Grizzly o Xsocket. Al contrario que la mayora del
cdigo JavaScript, no se ejecuta en un navegador, sino en el servidor.
Node.js implementa algunas especificaciones de CommonJS.5 Node.js
incluye un entorno REPL para depuracin interactiva.

10.

Anexo

11.

Bibliografa
https://prezi.com/2uraxobilh0t/tipos-de-arquitecturas-de-software/
http://xurxodeveloper.blogspot.pe/20114/01/ddd-la-logica-de-dominioes-el-corazon.html
https://prezi.com/g_k6fdrg_rmd/arquitectura-ddd-net/
http://es.slideshare.net/lilyPacheco7/arquitectura-de-software13925226
https://es.wikipedia.org/wiki/Node.js