Hola buen día instructor. Tengo una pregunta, como es en todos los casos va a haber mas estructuraras, ¿como seria un correcto manejo de paquetes en ese caso? es decir, en el crud, en el paquete handler solo se trabaja con una estructura, de ahí surge mi pregunta para cuando la aplicación crece.
Hola buen día instructor. Tengo una pregunta, como es en todos los casos va a haber mas estructuraras, ¿como seria un correcto manejo de paquetes en ese caso? es decir, en el crud, en el paquete handler solo se trabaja con una estructura, de ahí surge mi pregunta para cuando la aplicación crece.
Hola buen día instructor. Tengo una pregunta, como es en todos los casos va a haber mas estructuraras, ¿como seria un correcto manejo de paquetes en ese caso? es decir, en el crud, en el paquete handler solo se trabaja con una estructura, de ahí surge mi pregunta para cuando la aplicación crece.
La estructura de paquetes es un tema que no se alcanza a ver en este curso. Espero pronto hacer uno donde veamos algunas alternativas. Ya que es un tema tan complejo que cada empresa utiliza diferentes formas de estructurar sus proyectos.
Puedes utilizar arquitectura hexagonal, arquitectura onion para estructurar tu proyecto, en el caso de Go la estructura podria ser como sigue:
/
|---/cmd
|----main.go
|---/domain
|---/models
|---user.go
|---student.go
|---/interfaces
|---users_service.go
|---students_service.go
|---users_repository.go
|---students_repository.go
|---/application
|---/services
|---users_redis_service.go (esto es la implentacion de la interfaz)
|---students_redis_service.go
|---/infrastructure
|---/data
|---users_redis_repository.go (contiene la implementacion de la interfaz)
|---students_redis_repository.go
Algunos consideran que modular en go permitiria tener una visibilidad de todas las clases por dominio, en lo personal a mi me da flojera tener todo en una misma carpeta y luego estar distinguiendo por el paquete ejemplo
Prefiero el enfoque Hexagonal
data.UsersRedisRepository, data.StudentsRedisRepository
services.UsersRedisService, services.StudentsRedisService
Me parece un enfoque mas organico y que permite crecer la aplicacion sin que te hagas pelotas con tanto nombre similar
Saludos
La estructura de paquetes es un tema que no se alcanza a ver en este curso. Espero pronto hacer uno donde veamos algunas alternativas. Ya que es un tema tan complejo que cada empresa utiliza diferentes formas de estructurar sus proyectos.
Puedes utilizar arquitectura hexagonal, arquitectura onion para estructurar tu proyecto, en el caso de Go la estructura podria ser como sigue:
/
|---/cmd
|----main.go
|---/domain
|---/models
|---user.go
|---student.go
|---/interfaces
|---users_service.go
|---students_service.go
|---users_repository.go
|---students_repository.go
|---/application
|---/services
|---users_redis_service.go (esto es la implentacion de la interfaz)
|---students_redis_service.go
|---/infrastructure
|---/data
|---users_redis_repository.go (contiene la implementacion de la interfaz)
|---students_redis_repository.go
Algunos consideran que modular en go permitiria tener una visibilidad de todas las clases por dominio, en lo personal a mi me da flojera tener todo en una misma carpeta y luego estar distinguiendo por el paquete ejemplo
Prefiero el enfoque Hexagonal
data.UsersRedisRepository, data.StudentsRedisRepository
services.UsersRedisService, services.StudentsRedisService
Me parece un enfoque mas organico y que permite crecer la aplicacion sin que te hagas pelotas con tanto nombre similar
Saludos
La estructura de paquetes es un tema que no se alcanza a ver en este curso. Espero pronto hacer uno donde veamos algunas alternativas. Ya que es un tema tan complejo que cada empresa utiliza diferentes formas de estructurar sus proyectos.
Puedes utilizar arquitectura hexagonal, arquitectura onion para estructurar tu proyecto, en el caso de Go la estructura podria ser como sigue:
/
|---/cmd
|----main.go
|---/domain
|---/models
|---user.go
|---student.go
|---/interfaces
|---users_service.go
|---students_service.go
|---users_repository.go
|---students_repository.go
|---/application
|---/services
|---users_redis_service.go (esto es la implentacion de la interfaz)
|---students_redis_service.go
|---/infrastructure
|---/data
|---users_redis_repository.go (contiene la implementacion de la interfaz)
|---students_redis_repository.go
Algunos consideran que modular en go permitiria tener una visibilidad de todas las clases por dominio, en lo personal a mi me da flojera tener todo en una misma carpeta y luego estar distinguiendo por el paquete ejemplo
Prefiero el enfoque Hexagonal
data.UsersRedisRepository, data.StudentsRedisRepository
services.UsersRedisService, services.StudentsRedisService
Me parece un enfoque mas organico y que permite crecer la aplicacion sin que te hagas pelotas con tanto nombre similar
Saludos