Creación del documento de diseño

Me parece importante el hecho de poner lo que está fuera del alcance, aunque seguramente muchas personas puedan decirte: ¿y por qué no los ponemos? Siempre me pasa jaja.
.
Adicionalmente aquí les dejo el template del Markdown aquí:

# Titulo: Template de documento de diseño
---
## Overview: Problema a resolver
Descripción..

### Alcance(Scope)
Descripción..

#### Casos de uso
Descripción...
* Caso de uso 1
* Caso de uso 2
* ...

#### Out of Scope (casos de uso No Soportados)
Descripción...
* Caso de uso 1
* Caso de uso 2
* ...
---
## Arquitectura

### Diagramas
poner diagramas de secuencia, uml, etc

### Modelo de datos
Poner diseño de entidades, Jsons, tablas, diagramas entidad relación, etc..

---
## Limitaciones
Lista de limitaciones conocidas. Puede ser en formato de lista.
Ej.
* Llamadas del API tienen latencia X
* No se soporta mas de X llamadas por segundo
---
## Costo
Descripción/Análisis de costos
Ejemplo:
"Considerando N usuarios diarios, M llamadas a X servicio/baseDatos/etc"
* 1000 llamadas diarias a serverless functions. $XX.XX
* 1000 read/write units diarias a X Database on-demand. $XX.XX
Total: $xx.xx (al mes/dia/año)

Recomiendo utilizar Typora para leer, crear y editar archivos markdown

Les comparto los casos de uso soportados y no soportados que agregue al documento:

#### Casos de uso
Descripción...
* Como editor me gustaria poder subir una review de una camara
* Como editor me gustaria poder subir una review de un lente para las camaras
* Como editor me gustaria poder subir review de accesorios para las camaras
* Como usuario no registrado me gustaria poder leer una review

#### Casos de uso No Soportados
Descripción...
* Como usuario no registrado me gustaria poder subir una review de una camara
* Como editor me gustaria dar feedback a otras review
* Como editor me gustaria aprobar comentarios en reviews de usuario registrados
* Como usuario no registrado me gustaria registrarme
* Como usuario no registrado me gustaria poder compartir una review en mis redes sociales
* Como usuario registrado me gustaria comentar en las reviews
* Como usuario registrado me gustaria dar seguimiento de los comentarios en la reviews que me interesan

Con el tema de caso de uso soportados y no soportados, ¿es una buena practica ser detallista? Por ejemplo, por que no solo decir en un caso de uso: Como editor me gustaria poder subir una review de una camara y de lentes para camaras. Si no que este caso se divide en dos. ¿Por que?

Las limitaciones me parecen complicadas de redactar. Poder dar la cantidad exacta (o aproximada) de los valores que queremos limitar, me parece que solo se dan cuando ya tenemos algo de experiencia en el tema. Si intento hacerlo con una API en un ambiente mas real, no sabria que numeros poner.

Las limitaciones no me convencen realmente como se estan redactando aca.

Casos de usos = Historias de usuarios

Mis casos de uso

• Como editor quiero subir un review de una camara
• Como editor quiero subir un review de lente para las camaras
• Como editor quiero subir un review de cualquier objeto relacionado con la fotogarfia
• Como lector quiero poder leer los reviews
• Como lector quiero puntear reviews
• Como lector quiero puntear comentar
• Como lector quiero viajar a travéz de categorias
• Como lector quiero buscar reviews especificas
• Como administrador quiero gestionar mis editores

• Como usuario no registrado quiero subir un review de una camara
• Como usuario no registrado quiero puntear un review
• Como usuario no registrado quiero comentar en un review
• Como administrador quiero obtener estadisticas de los reviews

¿puedo utilizar este template para realizar un sistema aunque no sea api?

Comparto mi documento de diseño (El inicio). Es algo sencillo tecnica y funcionalmente.

# Sala de conciertos

---

## Overview: 

Se requiere visibilizar los proximos eventos de las agrupaciones musicales de forma ordenada según calendario. Estos eventos serán cargados por los mismos organizadores de los eventos o por las mismas bandas en una pantalla emergente de gestión. Una vez que cada evento se cree se generará un código único. de 8 digitos. Una vez cada evento alcance su fecha de ejecución más un día será retirado de la lista. Los eventos podrán ser eliminados de la lista con un código único generado. En caso de que haya varios eventos en la misma fecha, no se hará organización adicional.

### Alcance(Scope)

Desarrollo de un portal web de visualización libre de publicidad acorde a los eventos de agrupaciones musicales, la cual puede ser cargada, modificada y eliminada unicamente por los gestores del evento.

#### Casos de uso

Descripción...

* Como **espectador** quiero entrar a la página principal y ver un listado de los próximos eventos.
* Como **espectador** quiero ver el listado de los próximos eventos organizados por la fecha.
* Como **espectador** me gustaría al hacer clic, ver información más detallada del evento.
* Cómo **gestor** quiero ver un botón que me permita acceder a una página de gestión de eventos.
* Cómo **gestor** quiero poder ver dos opciones iniciales en la pantalla emergente de gestíon de eventos: Crear evento y Gestionar evento.
* Cómo **gestor** quiero poder crear un evento cargando el flyer de la banda y demás información asociada al mismo.
* Cómo **gestor** quiero recibir en mi celular un SMS y un correo indicando el código único de gestión del evento, una vez el evento haya sido creado.
* Cómo **gestor** estando ubicado en la pantalla de Gestionar Evento, quiero poder ingresar el código que recibí previamente.
* Cómo **gestor** al ingresar correctamente el código, quiero ver una ventana que me permita editar la información del evento o eliminarlo de ser requerido.

#### Out of Scope (casos de uso No Soportados)

Descripción...

* Como **espectador** me gustaría filtrar los eventos por fecha, ubicación, género, etc.
* Cómo **gestor** me gustaría personalizar la forma en que se visualiza mi evento.
* Cómo **gestor** me gustaría tener un botón de compra de boleteria en cada evento.
* Cómo **dueño del portal** me gustaría compartir automaticamente los eventos creados en todas mis redes sociales el día anterior y el dia del evento.

Feedback please…

Creacion de una infractructura backend basada en cloud computing y la creacion de una API que incluya los diferentes endpoints para poder cumplir con los casos de uso.

EL PUNTO ES QUE SE ENTIENDA

Hasta que punto es necesario poner lo que no se cubre con la arquitectura? en mi concepto esto no se debe poner, ya que puede salir infinidad de cosas que al cliente se le ocurran y que no esten especificadas en esta sección. Me parece que solo debe estar lo que cubre, lo que este en los casos de uso, lo que no este alli no esta contemplado y ya.

Aquí lo más importante es evaluar:
.
Cual es el problema que nosotros vamos a solucionar?

Lecturas versus Escrituras: 

.
Cuando nosotros estamos construyendo una aplicación que va a tener una gran cantidad
de escritura (rápida escritura) y poca lectura:

Modelar en DB SQL es lo mas sensato en su tercera forma normal para bajar el impacto en las actualizaciones
Aquí modelamos una vista a partir de varios JOINs y las escrituras en la tabla que corresponda

.
y al contrario cuando vamos a tener mas lecturas que escrituras, entonces:

Modelar en una base de datos no relacional para solucionar el problema del rendimiento, aunque no vamos a tener este problema al menos que estemos trabajando con datos y concurrencia a gran escala

Aquí modelamos una vista a partir de una colección, pero a la hora de actualizar la latencia cambia con respecto a DB SQL

Que tal usar el documento de diseño directamente como el README del respoitorio?

Es fundamental tener escrito esto, ya que da transparencia ya sea para el desarrollador como para el cliente…

Hola, cómo se podría validar el costo por usuario, por ejemplo el sistema esta soportado para 1000 usuarios por un costo X si deseas más usuarios te costará este otro dinero?