Como hemos visto luego de planear ya podemos comenzar escribir nuestro codigo, y si bien no quisiera entrar en temas muy iniciales de flutter y demas, si podemos obviar algunas cosas que necesitamos para comenzar:

Prerequisitos

Comenzaremos con que es importante tener Flutter instalado y Android Studio, entre otros pasos que puedes revisar aquí, primeramente para crear nuestro proyecto:

flutter create {nombre de directorio} --project-name {nombre de nuestro app}

Luego agregaremos las librerias que utilizaremos en nuestro proyecto:

flutter pub add supabase_flutter bloc flutter_bloc dartz get_it dio flutter_gen google_fonts error_stack cached_network_image equatable flutter_dotenv flutter_screenutil freezed_annotation gap go_router json_annotation pull_to_refresh skeletonizer toastification google_sign_in flutter_gravatar

a. Las librerias de soporte en el desarrollo que usaremos:

flutter pub add --dev bloc_test build_runner flutter_gen_runner freezed json_serializable mockito mocktail
Estructura
Como hemos mencionado, trabajaremos con la Clean Architecture, por lo que debemos organizar nuestros directorios de manera específica para no perdernos y cumplir con cada punto de dicha metodología. A continuación, implementaremos una estructura que me ha servido y que considero la más fácil de usar, aunque en internet encontrarás diferentes maneras de aplicar esta arquitectura.

Estructura

Comencemos con el primer nivel de directorios:

core: Aquí almacenaremos servicios y widgets comunes o compartidos.

features: Donde organizaremos las secciones principales de nuestra app.

gen: Es un directorio autogenerado que utiliza la librería flutter_gen para los assets que usemos. No es necesario generarlo manualmente, ya que se autogenerará más tarde.

main.dart: Contendrá nuestra función main, que correrá la app.

Core

Como mencionamos, nuestro directorio core almacenará todo lo relacionado con servicios y widgets compartidos en toda la app.

app: Almacena nuestra aplicación, donde agregaremos todo lo relacionado con las configuraciones de nuestra clase MainApp. Usualmente, se encuentra dentro de main.dart, pero es más limpio extraerla a su propio archivo.

routes: La configuración de nuestras rutas, donde usaremos GoRoute.

theme: Nuestra clase para configurar todo nuestro tema.

common: Contendrá todos nuestros widgets compartidos y clases que utilizaremos en servicios o dentro de la misma Clean Architecture.

services: Aquí irán nuestras clases de clientes de comunicación con las diferentes APIs que utilicemos o clientes HTTP. En nuestro proyecto, utilizaremos Supabase.

service_locator: Nuestra clase encargada de la inyección de dependencias.

Features

Nuestra organización estará centrada en funcionalidades (features), por lo que dentro de este directorio las dividiremos por nombre, y dentro colocaremos nuestra estructura de Clean Architecture.

data: Concentra la obtención de información de fuentes externas.

• data_source: Contiene las clases que utilizan nuestro servicio de API para obtener la información a utilizar.

• models: Son nuestras estructuras de datos primitivas, donde hacemos la transformación de JSON a data class de Dart. Principalmente, utilizamos este primer paso para hacer más sencillo su manejo dentro de nuestra app. Suelen ser una extensión de nuestras entities.

• repositories: Aquí se almacenan las implementaciones de los repositorios que se encuentran en domain. Es crucial que estas implementaciones se mantengan en la capa data para cumplir con los principios de la Clean Architecture.

domain: Concentra nuestra lógica ya transformada y compatible con nuestra app.

• entities: Son nuestros modelos, pero ya listos para su manejo dentro de la app. A partir de este punto, solo usamos las entities para mostrar nuestros datos en la app.

• repositories: Son la representación abstracta de nuestros repositorios, previamente implementados en la capa data. Mantener los repositorios en forma de interfaces en esta capa asegura la independencia de la lógica de negocio.

• use_cases: Son clases con propiedades que llaman a nuestros repositorios con un método call(). Entonces, por cada método de nuestro repositorio, existirá un use_case.

presentation: Engloba la parte visual de nuestra app, donde ahora sí utilizaremos los datos listos y “sanitizados” de nuestra app.

• bloc: Consumirá nuestros use_cases y hará las actualizaciones de estado de nuestra app, según las respuestas que reciba, ya sean satisfactorias o errores. Es importante mantener la lógica de presentación aislada de los detalles específicos de los casos de uso.

• pages: Teniendo en mente el pensamiento de diseño atómico de nuestros componentes, esta parte almacenará las moléculas que se complementarán de widgets que esperan recibir la data para mostrarla.

• widgets: Son la parte más pequeña de nuestra app, fragmentos que esperan recibir data para presentarla. A su vez, ejecutan acciones de nuestro bloc para recibirla o hacer cambios en nuestra app, como formularios, botones o URLs de imágenes para mostrarlas.

Es crucial recordar que la organización debe seguir principios claros de separación de responsabilidades y uso de abstracciones para mantener la integridad de la Clean Architecture.

Esto ha sido un monton de información que degerir, pero es mucho más sencillo de lo que parece. En nuestro siguiente capitulo veremos que código va en donde y por qué. Por lo pronto esta es una explicación rápida de como organizar nuestro código y proyecto con Clean Architecture.

Gracias por leerme y cualquier duda estoy a la orden en los comentarios.

Happy coding!