Curso de CLEAN ARCHITECTURE (Arquitectura Limpia) en Swift [Parte 1]
Вставка
- Опубліковано 18 вер 2023
- Aprende a crear una App iOS con CLEAN ARCHITECTURE o ARQUITECTURA LIMPIA desde 0.
Ya puedes ver todas las partes del curso aquí:
Parte 1: • Curso de CLEAN ARCHITE...
Parte 2: • Curso de CLEAN ARCHITE...
Parte 3: • Curso de CLEAN ARCHITE...
Parte 4: • Curso de CLEAN ARCHITE...
Parte 5: • Curso de CLEAN ARCHITE...
Suscríbete para no perderte ningún video del curso!
Fundamentos de Clean Architecture: • Aprende los 3 Fundamen...
Principios SOLID 👇
• ¿Qué son Principios SO...
Lista de Patrónes de Diseño: • Patrones de diseño sof...
Inyección de Dependencias: • ¿Qué es la INYECCIÓN D... - Наука та технологія
![Curso de CLEAN ARCHITECTURE (Arquitectura Limpia) en Swift [Parte 2]](http://i.ytimg.com/vi/o9hfPXcwSeY/mqdefault.jpg)
![Curso de CLEAN ARCHITECTURE (Arquitectura Limpia) en Swift [Parte 2]](/img/tr.png)
![Curso de CLEAN ARCHITECTURE (Arquitectura Limpia) en Swift [Parte 3]](http://i.ytimg.com/vi/5k6ZtUvjTYc/mqdefault.jpg)
Gracias me ha servido mucho este curso
Esos mapper son de gran ayuda!
Excelente explicacion, espero la siguiente parte!
Me ha tomado mi tiempo terminar la primera parte pero me emociona este proyecto porque me ayuda a aterrizar los conceptos, muchas gracias.
Muchas gracias a ti Cesar! Me alegra mucho que el curso te esté ayudando
Saludos!
Buen ejemplo, yo tambien maneno mis casos de uso en domain en android y estoy aprendiendo swift y esta guia me ayudata bastante a replicarlo en swift
Muchas gracias por el apoyo! Me alegra que te este ayudando
Uuuuuufffff esto es oro!!! Gracias maestro!!!
Esperando la parte 2.
Tremendo❤
Muchas gracias a ti por tus palabras y por el apoyo!
Saludos!
Tremendo contenido!! Gracias por compartir!!
Muchas gracias a ti por verlo!
Saludos!
Excelente, necesitaba una mejor manera de programar. Gracias por compartir tu conocimiento, podrías igual subirlo a Git para guiarnos
Muchas gracias Edmair!
Muy buena sugerencia! Estos días lo subiré y compartiré el link en la Parte 3.
Saludos!
buena!
Muchas gracias Carlos!
Saludos!
Esta bueno, hay conocimiento en ello pero siento que ya es ser demasiado purista entre otros detalles! Pero muy buen aporte para por la aclaración de los conceptos de Clean Architecture!
Muchas gracias!
Si por supuesto, para un proyecto pequeño esto es definitivamente sobreingeniería, pero para proyectos grandes con muchos desarrolladores trabajando en el mismo código acaba siendo necesario ser purista jaja.
Saludos!
Hay algun repositorio con el codigo, estoy teniendo un fallo, no consigo solucionarlo y me gustaria comparar. Gracias y buen video
Si claro, aquí lo tienes: github.com/srehouni/clean_architecture_tutorial_ios
Saludos!
Buen video. Como se define en que capa va cada necesidad? Es decir, tengo entendido que la lógica de negocio va en Domain, pero de ahí en que momento se debe crear Data? Que es lo que va en esa capa?
En este video explico lo que iría en cada capa y como saber diferenciarlas: ua-cam.com/video/WoT2Pm4_Bw0/v-deo.html
Respondiendo a tu pregunta, la lógica de negocio va en Domain si, pero esa lógica de negocio (casos de uso) necesitan de partes externas para realizar la acción. Al usuario le da igual que para realizar una acción tengas que obtener datos de una API o usar un framework específico, lo que quiere es que se haga lo que necesite. Por lo tanto todo lo que al usuario o al negocio "no le aporta nada" iría a capas mas externas. Una de esa capa es Data, que es básicamente lógica de datos. Como se obtienen esos datos, como interactuar con la API, como guardar los datos, etc..
Tiene relacion usar clean Architecture con DDD? o son 2 cosas separadas?
Muy buena pregunta!
Tiene relación si, ya que comparten los principios básicos, por lo tanto son complementarios.
DDD se enfoca mas en el Dominio, en cómo estructurarlo y en cómo tener un lenguaje común con los expertos de negocio. Esto tiene mucha utilidad cuando el proyecto tiene un dominio muy complejo. Si las reglas y lógica de negocio son de alta complejidad por la naturaleza del proyecto o del negocio, entonces tiene mucho sentido definir mas patrones y estrategias que ayudan con ello, y eso es lo que hace DDD.
Clean Architecture se enfoca en la separación estructural por capas, definiendo la responsabilidad de cada capa y haciendo hincapié en la regla de la dependencia.
Saludos!
Me pregunto ¿Será clean code meter varias clases o enums en un solo archivo? espero su respuesta
Hay casos en los que interesa tener clases o enums en el mismo fichero. Por ejemplo cuando tienes una clase a la que no quieras que se acceda desde fuera y que sea solo utilizada por una única clase, la puedes definir como privada y dejarla en el mimos fichero. Lo mismo con enums o structs. En estos casos tienes que tener en cuenta la inyección de dependencias, ya que esta clase no se puede instanciar desde fuera al tener una dependencia privada , por lo tanto tendrás que proveer de algún mecanismo para poder hacerlo como un factory.
Lo ideal es que cada cosa vaya en su correspondiente fichero.
Saludos!
Muy bueno el curso :D, una consulta porque no enviarle al builder las 3 listas para que el arme la lista de Cryptocurrency ?
Muchas gracias!
No se si te refieres al CryptocurrencyDomainMapper o al CryptocurrencyBuilder, pero te contesto para ambas:
- El CryptocurrencyDomainMapper ya construye la lista de Cryptocurrency, pero lo hace en 2 métodos diferentes para dividir la lógica. Se podría hacer todo en un único método pero acabaríamos con una método con muchas lineas.
- Si te refieres al CryptocurrencyBuilder, este solo se encarga de crear una Cryptocurrency cuando tenga todos los datos disponibles. Pasarle a este builder las 3 listas y que devuelva una única es lo que hace al final el CryptocurrencyDomainMapper.
Dime si esto respondido a tu pregunta o yo la he entendido mal.
Saludos!
@@SaidRehouni Era con respecto a CryptocurrencyDomainMapper. Me quedo super claro :) . Aplicando el principio KISS. Muchas gracias Said. 😄
Parte 2 del curso aquí 👇
ua-cam.com/video/o9hfPXcwSeY/v-deo.html
En la carpeta de casos de uso, que debe de ir? Cuál es la función de cada clase dentro de casos de uso?
La carpeta de casos de uso contiene las clases que representan las acciones que un usuario puede realizar. Esa es la definición de un caso de uso. Por ejemplo en el curso tenemos GetGlobalCryptoList, que representa la acción de
"obtener la lista de cryptocurrencies globales". En otras apps como la de un banco otro caso de uso sería "realizar un pago" o "consultar las últimas transacciones".
Saludos!
Gracias por ambas respuestas crack! Me quedó super claro con ambas explicaciones y el video enlazado.@@SaidRehouni
@@SaidRehouni tengo unas cuantas consultas sobre estos 4 videos, son menos de 10, te las dejo por acá o te las paso por otro medio? si no es mucha molestia
@@marcelovelasquezherrera4246 Si déjalas aquí mejor que seguramente ayudarán a otras personas también
@@SaidRehouni Vale, son muchas preguntas jeje, aquí las dejo: 1. Por qué para el UseCase Get Price History no creo un protocol con execute y para los otros si?
2. El try? result.get() se hace en GetGlobalCryptoList y GetCryptoList, eso se hace porque se manipula la data en esa clase? Ya que en GetPriceHistory no se manipula la data y no veo que se use result.get(). De ser el caso, que tipo de operaciones se pueden hacer en el UseCase ?
3. He visto que es recomendable usar MVVM para SwiftUI, que tan recomendable o común es usar otra arquitectura para SwiftUI? Entiendo que SwiftUI por su estructura se acomoda mejor a MVVM.
4. Una curiosidad, ¿Hay alguna razón en particular por la que en algunas clases API lo pones en mayúscula y en otra en minúscula? quizás sea para diferenciarlos por protocolos y clases
5. Veo que se creó una clase para un enum, he trabajado con una clase Enums donde colocaba todos los Enum de la app, cuál de las 2 es una buena práctica?
6. Veo archivos que no están en una carpeta a parte de Data y Domain. Se puede organizar mejor los archivos por tipo? Por ejemplo, el CryptoCurrencyBuilder y CryptoCurrencyDomainMapper están dentro de Data pero no dentro de otra carpeta. De ahí, en Presentation veo un archivo de Enum, dos struct, un mapper y view models. Los view models se podrían agrupar en una carpeta view model y los demás podrían pasarse a otras carpetas?
7. El nombre de los UseCase tiene alguna regla o el nombre es libre pero relacionado a su función?
8. En que casos se usa la propiedad actor? Solo para Singleton? Leí que era para garantizar la seguridad en la manipulación de datos compartidos.
9. Siempre que una función maneje una variable de datos se debe usar async? O solo si son datos de una api?
Casos de uso dentro del Domain??? madre mia si que Clean acada uno lo entendio como lo entendió.. Se supone que los UC conocen el dominio y eestan por fuera ..
Hay una clara separación entre entities y use cases como has podido ver y son los use cases los que conocen las entities. Quieres sacar los use cases y meterlos en un Application logic? Adelante. Pero los uses cases al representar lógica de negocio pertenecen al Domain. Domain no tiene porque ser una única capa
Saludos
@@SaidRehouni los UC los pongo en Application y tienen conocimiento del Dominio. no el dominio de los UC
@@moviedomof perfecto. Mientras se respete la regla de la dependencia todo bien. Entiendo que dentro de tu Domain solo tendrías entities.
@@SaidRehouni Entities VaolueObj.. + Contratos
@@moviedomofcasos de uso en application ? 🤡🤡🤡