Clean

architecture pdf español

Cualquier persona que haya trabajado como desarrollador durante, al menos, unos meses probablemente se ha enfrentado a situaciones en las que la aplicación en la que estaba trabajando, que al principio era amigable y estructurada, ha crecido tanto y tan rápido que contiene clases de más de 800 líneas de código. En ellas se pueden encontrar
elementos duplicados, métodos que realizan quince acciones diferentes y poco a poco van surgiendo dificultades para encontrar dónde se realizan determinadas acciones o incluso para realizar tareas que deberían ser triviales como crear test unitarios. Plantear una nueva funcionalidad o una ampliación de las ya existentes empieza a ser inviable sin
la perspectiva de invertir tiempo en refactorizar, y es en este momento en el cual empiezan a surgir incógnitas como: ¿qué ha pasado con mi proyecto?, ¿cómo hemos podido llegar a esta situación? Tras enfrentarnos a este problema, probablemente empecemos a investigar sobre arquitectura de software o hablemos con desarrolladores
experimentados. En ese camino, lo más probable, es que nos acabemos encontrando con las famosas siglas MVC (Model-View-Controller), vamos a intentar entenderlas: Model: son las clases que definen los datos de nuestra aplicación. View: es la interfaz propiamente dicha en definitiva el punto de entrada del usuario a nuestro producto. Controller:
son las clases en las que se van a realizar la captura de los eventos que suceden en la interfaz actuando en consecuencia. Además, de realizarse las interacciones con el modelo de la aplicación. Esta sencilla arquitectura no es la solución a todos nuestros problemas ya que si se aplica en sentido literal pueden aparecer dificultades. En pocas semanas
los controladores que venían con la promesa de solucionar nuestros problemas serán clases de miles de líneas que además de responder a eventos de la interfaz, realizarán llamadas a servicios web, obtendrán y almacenarán información en BBDD, realizarán validaciones, aplicarán reglas de negocio, y todo esto entre otras muchas tareas. Finalmente,
habremos implantado una arquitectura Massive-View-Controller, ya que ahora tendremos controladores que tendrán los mismos problemas que pretendíamos solucionar al principio. Ahora que parece que tenemos claro que existe un problema vamos a plantear unas sencillas preguntas, sobre situaciones del día a día: ¿Pondríais en vuestra cocina el
armario de la ropa? ¿Pondrías la ducha en el recibidor? ¿Tendríais la tv colgada encima de la vitro y la campana extractora de humos encima del sofá? Lo lógico tras estas preguntas es que penséis que me estoy equivocando de artículo, pero… ¿por qué si os escandalizan esas asunciones sobre la distribución del hogar, os parece lógico realizar
llamadas a servicios web en el mismo fichero que capturáis los eventos que suceden en la interfaz? Desde un punto de vista de ingeniería del software es tan extraño como cualquiera de las anteriores preguntas. Clean Architecture es un nombre popularizado por Robert Cecil Martin, conocido como “Uncle Bob” que se basa en la premisa de
estructurar el código en capas contiguas, es decir, que solo tienen comunicación con las capas que están inmediatamente a sus lados. Basados en esta idea podemos encontrar artículos que hablan sobre Clean Architecture, Onion Architecture, Hexagonal Architecture, todas ellas tienen diferentes enfoques, pero comparten la idea de que cada nivel
debe realizar sus propias tareas y se comunica únicamente con sus niveles inmediatamente contiguos. Los niveles de los que se compone Clean Architecture son los siguientes: UI: la interfaz de usuario propiamente dicha (html, xml, etc). Presenters: clases que se subscriben a los eventos generados por la interfaz y que responden en consecuencia,
también realizan el pintado de la información en la interfaz.
Use Cases: evaluación de reglas de negocio y tomas de decisiones. Entities: modelo de datos de la aplicación, comunicación con servicios web, cache de datos. Este es el gráfico original que propone Uncle Bob y se puede apreciar como los diferentes niveles anteriormente descritos sólo se comunican con los inmediatamente contiguos. A continuación,
tenemos otra interpretación del gráfico tradicional, en la que se han añadido descripción de las tareas que se suelen realizar en cada uno de los niveles. Cada uno de los niveles aquí representados podría considerarse dentro de la estructura de nuestra aplicación como carpetas independientes, diferentes módulos o librerías que se incluyen como
dependencias del proyecto principal o incluso podríamos aplicar este tipo de estructuración sin la necesidad de reflejarlo de forma explícita en la estructura del proyecto. Ahora que conocemos los fundamentos básicos de Clean Architecture, vamos a ver cuáles son algunas de las ventajas e inconvenientes a las que nos enfrentaremos si
decidimos aplicar esta metodología de trabajo en nuestro proyecto. Independencia: cada capa tiene su propio paradigma o modelo arquitectónico como si se tratara de una aplicación en si misma sin afectar al resto de los niveles. Estructuración: mejor organización del código, facilitando la búsqueda de funcionalidades y navegación por el mismo.
Desacoplamiento: cada capa es independiente de las demás por lo que podríamos reemplazarla o incluso desarrollar en diferentes tecnologías. Además de reutilizar alguna de ellas en diferentes proyectos. Facilidad de testeo: podremos realizar test unitarios de cada una de las capas y test de integración de las diferentes capas entre sí, pudiendo
reemplazarlas por objectos temporales que simulen su comportamiento de forma sencilla. Metodología: todo el equipo de desarrollo debe conocer la metodología que se está aplicando y cada desarrollador debe ser responsable de entender y aplicar las reglas establecidas a medida que está desarrollando. Complejidad: la velocidad de desarrollo al
comienzo del proyecto es menor debido a que hay que establecer esta estructura y todo el equipo debe adaptarse a la nueva forma de trabajar, pero poco a poco y a medida que la aplicación va creciendo el mantenimiento y ampliación será más sencillo. En mis años de experiencia como desarrollador, he probado diferentes aproximaciones a la hora
de comenzar un nuevo proyecto. La premisa que he intentado mantener como base es proporcionar al proyecto unos cimientos que ayuden al crecimiento y desarrollo del mismo. Para ello, últimamente he aplicado estos principios y puedo garantizar que la escalabilidad y mantenibilidad del código es mucho mayor, pudiendo invertir menos tiempo en
desarrollar nuevas funcionalidades o ampliar las ya existentes. Clean Architecture proporciona ideas sobre cómo organizar nuestro código en diferentes niveles. Pero la manera en la que estos se comunican entre sí, la organización interna de cada uno de ellos y la creación del árbol de directorios del proyecto, son algunas de las preguntas abiertas
que quedan en este artículo. Como he podido comprobar, durante el tiempo que he estado usando Clean, se pueden realizar diferentes combinaciones, todas y cada una de ellas válidas, para adaptarse a las necesidades del proyecto o incluso a las preferencias de los integrantes del equipo de desarrollo. Pero para mí lo más importante es la idea de
que cada clase que tenemos dentro de un proyecto tiene que cubrir únicamente el rol para el que ha sido creada y no abarcar más funcionalidades de las que debe, ya que esto generará dificultades futuras. Si tenemos clara esta idea, la aplicación de Clean será una progresión lógica en nuestra vida como desarrollador para mejorar la calidad de
nuestros productos. Abimael BareaAbimael es analista senior con experiencia en desarrollo de aplicaciones móviles. Ha trabajado con tecnologías nativas e híbridas como Java, Kotlin, Objective-C, Swift, Angular (Typescript). También con metodologías ágiles como SCRUM, realizada estimaciones, gestión de git, integración continua (Jenkins, Lint,
SonarQube). Por otro lado ha formado parte de evaluaciones de usabilidad de aplicaciones y del proceso de diseño de las mismas. Skip to contentClicking on content like buttons will cause content on this page to change.
Items will update when they are liked.tunatati1980@tunatati1980703clean architecture github pdf Robert Martin, más conocido como Tío Bob (Uncle Bob en inglés), plantea que la arquitectura de un software debe gritar cuál es el uso de dicho software. Así como al ver planos de edificios, si uno ve que el edificio posee un baño, cocina, comedor,
dormitorios, la arquitectura grita que es una casa familiar. De esta manera, al visualizar la arquitectura de un software, se debería notar cual es el uso del mismo. La arquitectura no debería indicar cuál es el framework o herramientas usadas para su construcción. Volviendo al arquitecto de edificios, el mismo se asegura que un edificio cumpla con los
casos de uso antes de decidir qué materiales se usarían para su construcción. En el caso del desarrollo de software, cumplimentar esto, asegura que el producto satisfaga los casos de uso y retrase la decisión sobre los frameworks o herramientas a usar. Incluso, una buena arquitectura basada en casos de usos permite que sea fácil cambiar la
herramienta que se va a usar. La arquitectura limpia La propuesta del Tío Bob sobre la arquitectura limpia impone las siguientes restricciones: Independente de frameworks: la arquitectura no debe atarse a las restricciones del framework. Esto permite considerar al framework como una herramienta.

Testeable: las reglas de negocios deberían poder probarse independientemente de la UI, base de datos u otras herramientas. Independiente de la UI: la interfaz de usuario se debería poder cambiar fácilmente sin necesidad de cambiar la lógica de negocio. Independiente de la base de datos: las reglas de negocios no deberían estar ligadas a la base de
datos o herramienta de persistencia. La regla de la dependencia El diagrama presenta una arquitectura basada en “capas de cebolla”, enfoque propuesto por Jeffrey Palermo. Cada círculo concéntrico representa aspectos diferentes del software. Las capas exteriores dependen de las interiores. Pero no debería ocurrir el caso inverso, los círculos
interiores no debe saber nada de los exteriores.
Incluso la base de datos es externa, rompiendo con la idea de “aplicaciones de base de datos” o modelos altamente ligados a la herramienta de base de datos. Entidades Encapsulan la lógica de negocio de la empresa. Una entidad puede ser un objeto con métodos, o puede ser un conjunto de estructuras de datos y funciones. Encapsulan la mayoría de
la lógica general y de alto nivel; y deberían poder reutilizarse en las diferentes aplicaciones de la empresa. Las entidades deberían ser las menos propensas a sufrir cambios debidos a un cambio externo. Por ejemplo, no se espera un cambio en las entidades habiendo modificado algún aspecto de la UI o la seguridad. Ningún cambio operacional de una
aplicación particular debería afectar a la capa de entidades. Casos de uso Esta capa contiene las reglas de negocio específicas de la aplicación. Encapsula e implementa todos los casos de uso del sistema. Éstos dirigen el flujo de datos hacia y desde las entidades y hacen que las entidades usen su lógica de negocio para conseguir el objetivo del caso
de uso. Los cambios en esta capa no deberían afectar a las entidades. Tampoco se espera que cambios externos como en la base de datos, framework o la interfaz gráfica afecten a esta capa. Sin embargo, sí se esperan cambios en las operaciones de la aplicación afecten a los casos de uso. Es decir, si detalles de un caso de uso cambian, entonces algo
de código de esta capa va a cambiar.

Adaptadores de interfaz Esta capa contiene un conjunto de adaptadores que convierten los datos desde el formato más conveniente para el caso de uso y entidades al formato más conveniente o aceptado por elementos externos como la base de datos o la UI. Los presentadores, vistas y controladores pertenecen a esta capa. Los modelos son sólo
estructuras que se pasan desde los controladores a los casos de uso y de vuelta desde los casos de uso a los presentadores y/o vistas.
Del mismo modo, los datos son convertidos en esta capa, desde la forma de las entidades y casos de uso a la forma conveniente para la herramienta de persistencia de datos. En este círculo se encuentran también los demás adaptadores encargados de convertir datos obtenidos de una fuente externa, como un servicio externo, al formato interno usado
por los casos de uso y las entidades. Frameworks y drivers El círculo más externo se compone generalmente de frameworks y herramientas como la base de datos, el framework web, etc. Generalmente en esta capa sólo se escribe código que actúa de “pegamento” con los círculos interiores. En esta capa es donde van todos los detalles. La web es un
detalle. La base de datos es un detalle. Se mantienen estas cosas afuera, donde no pueden hacer mucho daño. Cruzando la frontera En el gráfico se ve un ejemplo de cómo se cruzan las fronteras del círculo. Muestra cómo los controladores y presentadores se comunican con los casos de uso del círculo interno. El control del flujo empieza en el
controlador, atraviesa el caso de uso y finaliza en el presentador. La dependencia a nivel de código fuente apunta hacia adentro, hacia los casos de uso. Se resuelve esta supuesta contradicción usando el principio de inversión de dependencia, es decir, desarrollando interfaces y relaciones de herencia de tal manera que las dependencias de código
fuente se oponen al flujo de control en sólo algunos puntos a través de la frontera. Considerando que los casos de uso necesitan llamar al presentador, esta llamada no debe ser directa ya que se violaría el principio de la regla de dependencia. Ninguna implementación de un círculo exterior puede ser llamado por un círculo interior. En esta situación el
caso de uso llama a una interfaz definida en el círculo interno y hace que el presentador implemente dicha interfaz en el círculo exterior. Los datos que cruzan la frontera Las estructuras de datos que se pasan a través de las fronteras deben ser simples.
No se debería pasar entidades o filas de base de datos. Muchos frameworks de base de datos devuelve los datos en el formato de respuesta de una query. Por ejemplo, un RowStructure. Pasar los datos en ese formato violaría la regla de dependencia obligando a un círculo interno saber algo sobre un círculo exterior. Las estructuras de datos que
tienen cualquier tipo de dependencia con capas exteriores viola la regla de dependencia. Los datos que cruzan las fronteras deben ser estructuras de datos simples. Se puede utilizar estructuras básicas u objetos Data Transfer. O los datos pueden ser argumentos en las llamadas a funciones.
O bien, almacenar en un diccionario o hash. Cuando se pasan datos a través de una frontera, siempre debe ser en la forma más conveniente para el círculo interior. Diferencias con patrón arquitectónico MVC El patrón MVC distingue 3 componentes: Modelo: es el software del dominio de la aplicación, contiene la lógica del negocio. Controlador:
contiene las interfaces que asocia el modelo, las vistas y los dispositivos de entrada. Vista: Muestra los datos del modelo y refleja sus cambios. Este patrón considera la presencia de una única vista o controlador.

Lo que ocurre cuando hay múltiples vistas es lo siguiente: En la mayoría de los frameworks de UI actuales, especialmente los de aplicaciones móviles, los componentes de las vistas suelen ser también controladores, por ejemplo, un botón “virtual”, siendo difícil aplicar el patrón MVC tal como fue concebido en sus orígenes. También se nota la ausencia
de especificación del almacenamiento de los datos del modelo o interacción con otros servicios como internet, aspectos muy recurrentes en aplicaciones modernas. Este patrón es relativamente sencillo, siendo que en la actualidad no sea muy útil su uso para arquitectura de aplicaciones. Sin embargo, el patrón MVC o similares sigue siendo usado
para el manejo de la vista y los eventos, por lo que se puede seguir usando dentro de la capa de presentación de las aplicaciones. Relación con patrón Layers Como se mencionó anteriormente, Clean Architecture está basada en capas en formas de “aros de cebolla”.
Dada la restricción de la regla de la dependencia, se puede relacionar cada capa de la arquitectura propuesta con cada capa del patrón arquitectónico Layers. Experiencia en el desarrollo de aplicaciones móviles Las aplicaciones móviles poseen muchas limitaciones inherentes a la plataforma comparado con una computadora de escritorio, como la
limitación energética, acceso a internet escaso, pantalla reducida. Sin embargo, el aumento de las especificaciones técnicas de los equipos como de la calidad del servicio de internet móvil ha posibilitado el crecimiento en funcionalidad de las aplicaciones móviles, con su consecuente crecimiento en cantidad y complejidad del código.
Además, la frecuencia con la que se actualizan los sistemas operativos móviles y los frameworks de desarrollo es vertiginosa. Esta situación obliga a tener un mayor compromiso en el diseño de la arquitectura para que la misma posibilite un buen rendimiento general, como también que sea fácil de mantener por parte de los desarrolladores. El patrón
arquitectónico más primitivo para el desarrollo de aplicaciones con interfaces gráficas es el patrón MVC. Sin embargo, en las aplicaciones modernas (incluyendo las de escritorio) hay un alto acoplamiento entre la vista y el controlador. Lo sugerente es que Apple promueve el uso de MVC, disponiendo una clase llamada ViewController, generando el
acoplamiento de la vista y el controlador en una única clase, efecto que los desarrolladores han llamado Massive View Controller. Hay muchas variantes alternativas, entre ellas MVP y MVVM. Incluso existe librerías de programación reactiva. Sin embargo, sus diseños e implementaciones siguen siendo acotados y no cubren varios aspectos. Debido a
que las aplicaciones móviles hace uso de internet y a que el mismo es intermitente, es imperante la interacción con servicios externos y la persistencia de los datos en el dispositivo, elementos que ninguno de los patrones mencionados contempla. Que un patrón de arquitectura no contemple dichas situaciones da origen a problemas como llamadas a
un servicio web o acceso a base de datos directamente desde las clases de la vista o el presentador, afectando a la mantenibilidad del código a futuro. El criterio de Clean Architecture parece adecuado para resolver los problemas planteados a pesar de que no se tiene constancia de uso de este criterio en alguna aplicación conocida. Sin embargo ha
surgido material que propone ideas para su implementación. Tanto para Android como iOS, la comunidad de desarrolladores han realizado diversas propuestas de la implementación de Clean Architecture. Google dispone de un repositorio en GitHub que contiene ejemplos de arquitectura para aplicaciones Android. Uno de los ejemplos consta de una
posible implementación de Clean Architecture. Apple no ha provisto información sobre la arquitectura de aplicaciones iOS. Una propuesta de Clean Architecture Una propuesta tradicional, pero adaptada para aplicaciones móviles, es la de Fernando Cejas, desarrollador de Android. Su propuesta es dividir el proyecto de la aplicación en 3 grandes
capas (layers), cada una con propósitos diferentes y que funcionan separadas de las demás. Incluso hace mención a que cada capa tiene su propio modelo de datos para alcanzar la independencia entre ellas. El esquema propuesto es el que se muestra a continuación: Sin embargo, esta separación en capas es más bien conceptual. Es decir, los
elementos de cada capa no estarán separados mediante un facade, ni siquiera separados físicamente en directorios diferentes.
Esto es así porque, si se clasificaran los archivos según su tipo, regresaría una de las problemáticas que ataca Clean Architecture: que la arquitectura no “grite” lo que hace. Además, cada pantalla de una aplicación móvil, por lo general, responde a un caso de uso particular. Siendo natural en el desarrollo móvil agrupar los archivos relacionados a
cada pantalla, se propone incluir los interactores de casos de usos junto con los correspondientes archivos de la capa de presentación. La organización de los archivos propuesta para proyectos móviles es la siguiente: Models: Contienen los archivos de las entidades de la lógica de negocio (capa de dominio) Services: Implementaciones de los workers
y servicios de la capa de datos Store: herramientas y elementos para almacenar las entidades del dominio en una base de datos u otra forma de persistencia local Network: herramientas y elementos para conectarse a una API o cualquier recurso de Internet Workers: Generalmente contiene, para cada elemento del modelo, una interfaz que define las
operaciones para obtener, crear, modificar y/o eliminar los elementos del modelo en la capa de datos. Son interfaces que forman parte de la capa de dominio y se definen para que las implementen los distintos servicios Scenes: Elementos relacionados con la capa de presentación UseCase: Elementos del caso de uso en cuestión Interactor: Elemento
que contienen las reglas de negocio del caso de uso en cuestión (capa de dominio) Presenter: Elemento que adapta los modelos del dominio para presentarlos a la vista View: Elementos de la vista Worker: Elemento que obtiene los datos que solicita el interactor (capa de datos) Router: Elemento que contiene la lógica de navegación entre las vistas,
realizando las configuraciones necesarias como pasar datos, establecer valores necesarios al inicio, etc. Capa de dominio Esta capa contiene todas las entidades y reglas de negocio (casos de usos). Contiene también las implementaciones de los interactores. Esta capa debe estar escrito en el lenguaje puro de la plataforma, sin ninguna dependencia
con el SDK o UI. Todos los componentes externos utilizan interfaces para conectarse con los objetos de negocio.
Capa de presentación Contiene la lógica relacionada con las vistas y animaciones. Se puede usar Modelo Vista Presentador (MVP) o cualquier otro patrón de vista como MVC o MVVM. No hay lógica en esta capa, excepto la de interfaz de usuario.

Para esta capa se propone utilizar una idea de Raymond Law, que consiste en diseñar la presentación como un ciclo, llamado VIP, el cual tiene un diseño que se acerca al propuesto por el Tío Bob sobre la interacción entre elementos de la frontera de 2 capas (en este caso, capa de dominio con la capa de presentación). Los elementos del ciclo VIP se
relacionan de la siguiente manera Se trata de un ciclo unidireccional, es decir, la salida de la vista se comunica con la entrada del interactor; la salida del interactor se comunica con la entrada del presentador; la salida del presentador se comunica con la entrada de la vista. Pero recordemos que el interactor es parte de la capa de dominio, no debería
llamar directamente al presentador, el cual forma parte de la capa de presentación. Para ello se diseñan las interfaces adecuadas para que se respete la regla de dependencia de Clean Architecture. Las llamadas realizadas desde la vista no deben ser bloqueantes, para evitar afectar el rendimiento de la aplicación. Cualquier operación bloqueante que
realice el interactor u otro elemento deben realizarse en otro thread.
Capa de datos Todos los datos necesarios para la aplicación provienen de esta capa a través de una implementación de la interfaz que se encuentra en la capa de dominio. Utiliza un patrón de repositorio con una estrategia de elegir diferentes fuentes de datos en función de ciertas condiciones.

Por ejemplo, cuando se desea conseguir un usuario por ID, se selecciona la fuente de datos de caché de disco, si el usuario ya existe en la caché, de lo contrario se consultará en la nube para recuperar los datos y luego guardarlo en la memoria caché de disco. La idea detrás de todo esto es que el origen de datos es transparente para el cliente, no le
interesa si los datos provienen de memoria, disco o la nube, la única verdad es que los datos llegarán y serán conseguidos. Una propuesta, ya adelantada en la estructura de directorios del proyecto, es definir para cada elemento del dominio una interfaz de un repositorio para esa entidad y que en el directorio de servicios se implemente. Manejo de
errores Hay 2 enfoques posibles. Por un lado se pueden usar callbacks para la respuesta del repositorio de datos, por ejemplo, el callback puede contener 2 métodos: onResponse() y onError(). La última debe encapsular las excepciones en una clase contenedora. Este enfoque tiene algunas dificultades porque causan cadenas de callbacks hasta que el
error llegue a la capa de presentación para ser presentados. La legibilidad del código puede ser afectada. Otro enfoque es implementar un sistema de bus de eventos que lanza eventos si algo ocurre algo no deseado, pero este tipo de solución es como usar un GOTO. Recapitulando, interacción global A continuación se muestra un gráfico más
integrador sobre cómo interactúan los elementos descripto anteriormente.
Acomodando los elementos en las capas propuestas inicialmente, resulta el siguiente esquema. Una mirada práctica de Clean Architecture FIUBA desea construir un sistema que permita, para un cuatrimestre dado, enumerar los cursos ofrecidos por materia y permitir la inscripción a los cursos. El alumno no puede inscribirse a más de 7 cursos por
cuatrimestre. Casos de usos identificados Mockup de la aplicación Aclaraciones sobre la implementación Por lo general, este tipo de aplicaciones suelen comunicarse con un servicio web, estando toda la lógica de negocio fuera de la aplicación móvil. A modo de ejemplo, se prescindió del desarrollo de un servicio web y se incluyó la lógica en la
aplicación móvil. Los datos de las asignaturas y cursos son provistos mediante un JSON estático y luego son almacenados los cambios localmente, en una base de datos. Según la consigna, la cantidad máxima de cursos en que un alumno se puede inscribir es 7. Debido a que la cantidad de asignaturas provistas por las aplicaciones implementadas es
menor, se redujo el límite de inscripciones a un valor en el cual se pueda mostrar ejemplificar la situación del caso de uso correspondiente. Conclusión Inicialmente la experiencia nos indicó que había que escribir mucho código, aún para vistas y casos de usos relativamente sencillos. Sin embargo, tener bien definida la responsabilidad de cada
elemento, el desarrollo y los cambios se pueden hacer de forma incremental. Por ejemplo, desarrollar bien el caso de uso y luego la vista (o viceversa, situación común en el desarrollo de aplicaciones móviles). Además, el rendimiento de la aplicación no ha sido afectada a pesar de que se instancian muchos objetos por cada caso de uso implementado.
De todas maneras, recordemos que la aplicación de ejemplo es relativamente simple y no tiene interacción con Internet, una de las operaciones más lentas. Aún nos queda definir bien cómo manejar los errores, detalle que tampoco ha sido expuesto con claridad por las propuestas actuales de la comunidad de desarrolladores. El problema que nos
hemos encontrado en este apartado es que la capa de presentación está totalmente aislada de la capa de datos (lugar común donde ocurren errores, ya sea por falta de internet, timeout, etc) y la capa de dominio no debería manejar los errores, ya que incluiría elementos del SDK de la plataforma en que se desarrolla. Como conclusión, la propuesta
expuesta en el presente trabajo es un buen puntapié para seguir refinando la idea de Clean Architecture en base a la experiencia de desarrollo y la participación de la comunidad de desarrolladores. Bibliografía CEJAS, F. (2014). Architecting Android…The clean way?. Fernando Cejas Blog.
GOOGLE (2016). Android Architecture Blueprints [beta]. GitHub. KRASNER, G. E., POPE, S. T. (1988). A Description of the Model-View-Controller User Interface Paradigm in the Smalltalk-80 System. ParcPlace Systems, Inc.
//www.itu.dk/courses/VOP/E2005/VOP2005E/8_mvc_krasner_and_pope.pdf LAW, R. (2015). Clean Swift iOS Architecture for Fixing Massive View Controller. Clean Swift. MARTIN, R. (2011). Screaming Architecture. 8th Light Blog. MARTIN, R. (2011). Architecture the Lost Years. Ruby Midwest 2011.
MARTIN, R. (2012).
The Clean Architecture. 8th Light Blog. MARTIN, R. (2012). Clean Architecture. NDC Conferences. PALERMO, J. (2008). The Onion Architecture. Part I. Jeffrey Palermo Blog. You're Reading a Free Preview Pages 6 to 12 are not shown in this preview.