Clean Architecture con Python¶
¿Qué es Clean Architecture?¶
Clean Architecture o arquitectura limpia, es un compendio de principios y patrones de desarrollo que tienen como objetivo el facilitar el proceso de construcción del software, así como su mantenimiento.
Beneficios¶
- Creación de aplicaciones desacopladas que son más fáciles de probar
- Mayor flexibilidad para añadir o remover funcionalidades del software
- Diseño basado en componentes con responsabilidades bien definidas
- Aplazamiento de decisiones críticas hasta el último momento requerido
Usos¶
- Aplicaciones de negocios proyectadas para estar en operación indefinidamente.
- Sistemas distribuidos que se beneficien de un diseño desacoplado (e.g. usando microservicios).
- Infraestructuras heterogeneas a nivel de bases de datos, servicios web, etc.
- Aplicaciones pensadas para ser extendidas por terceros a través de plugins.
Fundamentos¶
Podría decirse que Clean Architecture no inventa nada nuevo, sino que agrupa metodologías, principios y patrones de diseño conocidos en la industria del software desde hace décadas. Sin embargo, lo que Clean Architecture sí trae a la mesa es su objetivo: crear aplicaciones flexibles que sean fáciles de mantener en el tiempo.
SOLID¶
S-ingle Responsability Principle
Un módulo debería tener una, y sólo una, razón para cambiar
Un módulo debería ser responsabilidad de un sólo actor
O-pen/Closed Principle
Un artefacto de software debería estar abierto para su extensión pero cerrado para su modificación
L-iskov Substitution Principle
Lo que se quiere aquí es algo como la siguiente propiedad de substitución: Si para cada objeto *o1 de tipo S hay un objeto o2 de tipo T, tal que para todos los programas P definidos en términos de T, el comportamiento de P no se modifica cuando o1 es substituido por o2 entonces S es un subtipo de T.
Barbara Liskov, 1988
I-nterface Segregation Principle
Es perjudicial depender de módulos que contienen más de lo que se necesita
Varias interfaces específicas por cliente son mejores que una sóla interfaz de propósito general
D-ependency Inversion Principle
Los sistemas más flexibles son aquellos en los que las dependencias de código se refieren a abstracciones y no a concreciones
Tipos de Programación¶
Programación Estructurada
Impone disciplina en la transferencia directa de control
Resuelve el problema de los ‘GOTO’ mediante la iteración y selección
Programación Orientada a Objetos
Impone disciplina en la la transferencia indirecta de control
Resuelve el problema de los punteros a funciones mediante clases y objetos
Programación Funcional
Impone disciplina en la asignación
Resuelve problemas de condiciones de carrera mediante la inmutabilidad
Modelado del Dominio¶
El núcleo de una aplicación es el dominio que tiene como propósito modelar. Este dominio se representa a través de lo que llamamos, la lógica de negocio.
Implementación¶
La Regla de las Dependencias¶
Las dependencias de una aplicación deben dirigirse en la vía de mayor abstracción.
Capas y Fronteras¶
Los componentes de una aplicación se comunican entre sí a través de fronteras bien definidas.
Los Detalles¶
Las consideraciones de infraestructura son sólo detalles del sistema. La base de datos, el framework web, las librerías de consola, son sólo herramientas de nuestras aplicaciones y no su esencia.
“For the framework author, coupling to his or her own framework is not a risk…”
“The author wants you to couple to the framework, because once coupled in this way, it is very hard to break away.”
Uncle Bob
El Componente Principal¶
El más sucio de los componentes. Es el encargado de instanciar el arbol de dependencias para crear la aplicación final.
Las Pruebas¶
Las pruebas o tests son el componente más externo de nuestra aplicación. A pesar de que no pueden asegurar que nuestras aplicaciones son correctas, si pueden informarnos que no son incorrectas y prevenir regresiones durante el desarrollo.
Proyecto Taskit¶
¡Para que no se te olvide!
Descripción¶
Realizaremos una aplicación para gestionar nuestras tareas por realizar. En general, la estructura de la aplicación estará compuesta por:
La aplicación nos permitirá:
- Crear, leer, modificar y eliminar nuevas tareas y proyectos.
- Asignar tareas a proyectos específicos.
- Mover las tareas por las distintas etapas del proyecto hasta el estado de cierre.
Obtendremos información valiosa para analizar detalladamente nuestro trabajo pudiendo:
- Reportar todas las tareas registradas.
- Reportar todos los proyectos registrados.
- Reportar todas las tareas pertenecientes a un mismo proyecto.
- Reportar todas las tareas con la misma etapa.
Preparación¶
- Asegurarse de tener instalado Python 3.5+
- Clonar el repositorio del proyecto: git clone https://github.com/nubark/clean-architecture-python.git
- Crear un nuevo virtual environment (e.g. clean-architecture-python)
- Instalar las dependencias del proyecto: pip install -r requirements.txt
- Hacer checkout a la rama feat/docs: git checkout feat/docs
Ejecución¶
El repositorio contiene 6 ramas de desarrollo incremental:
- feat/01_models
- feat/02_repositories
- feat/03_coordinators
- feat/04_infrastructure
- feat/05_reports
- feat/06_main
Cada una de ellas construye una capa o componente de la aplicación. En el proceso de recrear esta construcción, usaremos un enfoque de desarrollo guiado por pruebas (i.e. TDD). Esto asegurará que los componentes que diseñemos, se encuentren desacoplados desde el inicio y sean fáciles de extender.
Todos iniciarán en la rama feat/docs la cuál no contiene código. En el proyector se presentará el estado o rama objetivo. En la primera iteración esta rama será la feat/01_models. En la segunda iteración, cuando hayamos alcanzado el estado de la rama feat/01_models, la rama objetivo será la feat/02_repositories. Así lo haremos sucesivamente hasta completar la aplicación.
Dedicaremos un tiempo máximo de 15 minutos a cada fase. Si al completarse los 15 minutos no se ha terminado la totalidad de la funcionalidad requerida, lamentablemente tendremos que ejecutar git reset –hard. Por supuesto, pueden guardar sus cambios en una rama temporal si quieren (e.g. my/01_models). La idea es contar con el tiempo suficiente para abordar la totalidad de la aplicación. No se preocupen, tendrán tiempo de sobra para seguir el paso a paso en la comodidad de sus casas ;D
Comandos Importantes¶
Correr los tests con pytest:
pytest -s –cov-report term-missing –cov-branch –cov taskit tests
Empaquetar nuestra
pyinstaller -F taskit/__main__.py -n taskit
Finalmente¶
¡Manos a la obra!
Nubark¶
Información para decidir
Acerca de¶
Licencia¶
La documentación y el código de este repositorio se encuentra distribuida bajo la licencia MIT.
—
MIT License
Copyright (c) 2017 Nubark
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.