4. ARQUITECTURA
• Hace referencia a las decisiones de alto nivel, no tiene en cuenta los detalles de
bajo nivel.
• El objetivo es minimizar las personas requeridas para la mantenibilidad del
software.
5. DISEÑO
• Hace referencia a las decisiones de bajo nivel y estructuras.
• Su finalidad el cumplimiento de la funcionalidad.
6. Principios de diseño
• SOLID:
• Single Responsability Principle
• Open Close Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversión Principle
8. The reuse/ Release Equivalent Principle - REP
• La unidad de reuso es la unidad del release. El reuso efectivo deberá monitorear
un Sistema de control de reuso.
• El paquete (package) es la unidad de reuso y release.
• Para hacer efectivo el reuso deberemos incluir en nuestro Código el release de la
librería en nuesro código.
9. The Common Closure Principle - CCP
• Dentro de los componentes las clases deberían cambiar por las mismas razones y
en los mismos momentos.
• Deben separarse del componente aquellas clases que cambien en diferentes
momentos y por diferentes razones.
10. The Common Reuse Principle - CRP
• “Don’t forcé users of a component to depend on things they don’t need” Robert
Marin, Clean Architecture: A Crasftsman’s guide to Software Structure and Design
• Las clases y módulos que tienden a ser reusados deberían tender a ser reusados
juntos en el mismo componente.
11. CQRS PATTERN
• Command Query Responsibility Segregation.
• En modelos complejos se puede usar un
modelo diferente para actualizar (command)
la información que le usado para leerla
(query).
• https://martinfowler.com/bliki/CQRS.html
17. DCI
• James Coplien yTrygve Reenskaug.
• Data, Context, and Interaction.
• Data: representa el modelo con sus relaciones.
• Context: la instancia de la clase para un rol en una funcionalidad.
• Interaction: lo que el Sistema hace.
18. BCE
• Ivar Jacobson
• Entity Control Boundary
• Relacionado a crear componentes desacoplados sigiend el Open Close Principle,
Dependency Inversión e Interface Segregation.
20. ¿Qué se busca?
• Independiente de Frameworks
• Testeable
• Independiente de la interfaz de usuario
• Independiente de la base de datos
• Independiente de agentes externos
22. ¿En qué consiste?
• Las capas exteriores dependen de las interiores. Bajo ninguna circunstancia lo
contrario.
• Círculos interiores no conocen de los exteriores.
• No dependencias de detalles.
• Tener en cuenta la visibilidad de las clases para que no se viole la arquitectura.
23. ENTITIES
• Lógica de negocio.
• Acá se incluyen objetos con métodos de negocio y estructuras de datos que
representan el negocio.
• Cambios externos (UI por ejemplo) no deben afectar a estos elementos.
24. USE CASES
• Contienen las reglas de negocio de la aplicación.
• Dirigen el flujo desde y hacia las entidades. Las entidades usan la lógica de esta
parte para cumplir con la funcionalidad.
• Cambios en esta capa no deben afectar las entidades, tampoco cambios externos-
25. INTERFACE ADAPTERS
• Presenters, Gatweays, Controllers.
• Acá tendremos los adaptadores encargados de convertir los datos para la las
fuentes externas como base de datos o interfaz de usuario.
• También se incluye la conversion de los datos obtenidos de una fuente externa a
una que sea usada por los casos de uso y entidades.
26. FRAMEWORKS Y DRIVERS
• Herramientas como base de datos y framework.
• Se escribe el Código necesario para generar adaptación a los círculos interiors.
• Acá van los detalles como Web o bases de datos.
27. CRUZANDO LA
FRONTERA
• Llamados de capa externa a interna se
hace llamado usando interfaces.
• Las entidades que Cruzan las fronteras
deben ser simples. No deben ser entidades
o filas de base de datos que retorna una
consulta
• Estructuras de datos que tienen cualquier
tipo de dependencia con capas exteriors
viola la Arquitectura Limpia.
31. Bibliografía
• MARTIN, Robert. Clean Architecture: A Craftsman's Guide to
Software Structure and Design. Prentice Hall, 2017.
• 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.
http://web.archive.org/web/20150117044636/http://www.itu.dk/c
ourses/VOP/E2005/VOP2005E/8_mvc_krasner_and_pope.pdf
• LAW, R. (2015). Clean Swift iOS Architecture for Fixing Massive View
Controller. Clean Swift.
http://clean-swift.com/clean-swift-ios-architecture/
• MARTIN, R. (2011). Screaming Architecture. 8th Light Blog.
http://blog.8thlight.com/uncle-bob/2011/09/30/Screaming-
Architecture.html
• MARTIN, R. (2011). Architecture the Lost Years. Ruby Midwest
2011.
https://www.youtube.com/watch?v=WpkDN78P884
• MARTIN, R. (2012). The Clean Architecture. 8th Light Blog.
https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-
architecture.html
• MARTIN, R. (2012). Clean Architecture. NDC Conferences.
https://vimeo.com/43612849
• PALERMO, J. (2008). The Onion Architecture. Part I. Jeffrey Palermo
Blog.
http://jeffreypalermo.com/blog/the-onion-architecture-part-1/