Desde el mismo momento en que aprendí a programar me he dedicado a intentar hacer la cosas lo mejor posible y esto me llevó a investigar y desarrollar mis habilidades basándome en los principios SOLID.
He charlado con mucha gente acerca del modo en que organizan sus proyectos, patrones que utilizan o cómo afrontan la elección de arquitectura y confieso que me gusta la cantidad de opciones que aparecen y como te hacen pensar, pero sobre todo porque te da la posibilidad de llegar a tus propias conclusiones y poner en valor todas esas horas de charla y crear tu estructura en un proyecto propio.
Actualmente trabajo en un «side-project» que espero publicar en tiendas y estoy utilizando lo que denominan una estructura vertical, pero adaptada a mi visión de esa estructura, ya que veo un problema en este tipo de estructuras. Me explico.
Al crear una estructura vertical es cierto que tienes de un vistazo cada «Feature», pero al mismo tiempo cualquiera puede utilizar cualquier dependencia donde no debería, ya que todo está dentro del mismo «project» y es un arma de doble filo. Entiendo que esto no debería ser un problema y que haciendo revisiones de código y trabajando con «pull-request» quedaría resuelto, pero en esto estoy más en consonancia con un buen amigo, hay que limitar las acciones del desarrollador desde la arquitectura.
Todo esto me lleva a pensar en el título de este artículo y preguntarme, ¿realmente es simple o la complejidad inicial nos lleva a una simplicidad final?
En mi caso desarrollo aplicaciones móviles con Xamarin Forms y ReactiveUI y utilizo el patrón MVVM como base, por lo que trato de mantener mis ViewModels tan simples cómo sea posible, ya que su misión es únicamente proveer los datos a mostrar y el estado de la vista, lo que me obliga a tener servicios y repositorios que se encarguen del resto, aunque supongo que aquí es donde más diferencias habrá entre unos equipos y otros.
En mi caso, tuve una conversación con un amigo acerca de algo que llamó poderosamente mi atención, el único punto de la verdad, refiriéndose a éste como el único punto de la aplicación del que se pueden obtener datos, habitualmente nuestra base de datos, pero bien podrían ser archivos o cualquier punto de persistencia de datos que se te ocurra.
De igual modo, he visto cómo se hacía uso de los «UseCase«, que básicamente es que por cada caso de uso de tu aplicación tendrás una clase especializada en hacer sólo eso, de modo que podrás ir componiendo repositorios y servicios con los casos de usos que necesites y hacerle llegar los datos a tu ViewModel a través de éstos.
Una vez que lo voy escribiendo lo entiendo y comprendo que todo parece lógico, pero cuando lo llevas a la práctica se generan un buen número de proyectos dentro de la solución y me da la sensación de que introducir a desarrolladores con un perfil más junior se antoja una tarea compleja.
Por otro lado, creo que merece la pena introducir a los nuevos desarrolladores en la creación de software utilizando buenas prácticas, pero no sé si es la mejor de las ideas.
En fin, supongo que deben existir soluciones intermedias para limitar la acción de los desarrolladores y al mismo tiempo tener una estructura simple.
darioDotNet 