El sistema va a contar con 2 partes, una para los clientes y otra para los administradores/escritores, pero inicialmente todo en un único proyecto. Potencialmente pasaremos a 2 proyectos y una API en una futura versión, para poder plantear ideas sobre aplicaciones móviles, PWA, y otras ideas que puedan ocurrirsenos.
Arquitectura del blog
La arquitectura será una estructura de capas haciendo un vago intento de Domain Driven Design (DDD). Digo un intento de DDD porque al ser un proyecto pequeño, no requiere un nivel de complejidad tan alto como para aplicar Bounded Contexts, Event sourcing, CQRS u otros conceptos complejos, pero en si habrá cosas que sigan su filosofía general. Dicho sea, que no los implemente al inicio, no significa que en una futura versión no lo implementemos, siempre hay tiempo para refactorizar.
También vamos a aplicarle testing, pero nuevamente no siguiendo la idea del TDD del todo, pues no vamos a crear los tests antes del código. Principalmente haremos tests unitarios y de integración, pero es posible que cuando tengamos la versión 1.0 cerca de finalizar, añadamos algunos tests E2E.
Las capas que tendremos serán más o menos las típicas de este tipo de arquitectura: Dominio, Infraestructura, Aplicación (Servicios) y UI. Para los que no estéis muy acostumbrados, esta es la estrutura y flujo de referencias.
El objetivo de esta estructura es que sirva de esqueleto o contenido sobre el que podamos luego expandir “con facilidad” integrando nuevos módulos de funcionalidades, refactorizar, etc.
Identificación y seguridad
Para la versión 1.0 vamos a implementar un sistema de autentificación mediante cuentas individuales manualmente, pero usando de base el sistema de Identity y Claims que te ofrece nativamente .NET 6.
Digo que haremos implementaciones «manuales» porque en la generación del proyecto podríamos optar por tener toda la plantilla de Identity, con Entity Framework preconfigurado y muchas características implementadas por defecto. Pero si lo hiciera así entonces perderíamos la oportunidad de implementarlo manualmente y entender cómo funciona, así como decidir qué necesitamos realmente y no dejar que la plantilla nos añada complejidades que quizás no vayamos a necesitar en principio.
Es posible que también comente otras alternativas para el inicio de sesión como OAuth o JWT, así como temas de seguridad, pero será tangencial y opcional.
Aparte del sistema de identificación mencionado, añadiremos verificación en dos pasos, encriptación de contraseñas (hashing y salting) y el Google Captcha.
Acceso a datos e I/O
Las explicaciones van a estar escritas con ADO.NET y su equivalente en Entity Framework para que se vea claramente la equivalencia, de forma que seais libres de elegir la opción que más os convenga. Es posible que, dependiendo de la complejidad, podamos hacer repositorios híbridos con EF y ADO.NET.
En el proyecto oficial estaremos trabajando con ADO.NET mayormente por simplicidad a la hora de entender lo que solicitamos, pero procuraré implementar tests para ambas opciones.
Aparte de esto, vamos a necesitar poder subir archivos y almacenarlos localmente en el proyecto para nuestros thumbnails e imagenes de los posts. También explicarécómo podríamos integrar Azure Blob Storage y otros sistemas que pudieran interesarnos, como la api de Unsplash para no incluir imágenes directamente o tener un buscador interno.
Frontend y diseño
Con el fin de mantenerlo lo más sencillo posible, en el frontend usaremos:
- HTML5
- CSS3
- Javascript (sin frameworks adicionales)
- Bootstrap v5.2
Como diseños utilizaré los que nos ofrece gratuitamente Creative Tim. Para nuestro caso, estaré utilizando el Material Kit 2, pues es cómodo y está dentro de los requisitos. Sentíos libres de utilizar vuestras propias plantillas o diseñarla vosotros mismos, no afectará en gran medida a lo que vayamos a explicar.
En la parte pública vamos a tener un aviso sobre cookies y su gestión, así como sistemas para compartir por las redes sociales los post que la gente lea.
En la administración
Nos vamos a centrar en 2 roles,el escritor [E] y el admin [A]. Esta es una tabla de permisos:
| Página | Acción | Escritor | Admin |
|---|---|---|---|
| Posts | Full CRUD | – | X |
| CRUD para elementos propios | X | X | |
| Categories | Crear, Editar y Ver | X | X |
| Eliminar | – | X | |
| Tags | Crear, Editar y Ver | X | X |
| Eliminar | – | X | |
| Stats | Ver de posts propios | X | X |
| Ver todos | – | X | |
| Pages | Full CRUD | – | X |
| Users | Full CRUD | – | X |
| Menus | Full CRUD | – | X |
| Sidebars | Full CRUD | – | X |
| Widgets | Full CRUD | – | X |
La diferencia entre una «Page» (Página) y un «Post» (Artículo) es que las páginas son contenido estático que tendrá un diseño diferente (vamos a hacerlo de ancho completo sin un sidebar). Los posts tendrán fecha de creación y autor, mientras que las páginas no lo tendrán por defecto.
Los posts y páginas van a tener 2 estados: Draft (borrador) y Published (publicados). Si están en borrador entonces no podrán salir en la parte pública ni formar parte de los menús (en el caso de las páginas).
Dentro del creador de posts vamos a crear un sistema simple para validar características del SEO, previsualización del post en Google y previsualización de cómo se verá cuando se comparta en redes sociales.
Para mejorar nuestro SEO también implementaremos un servicio para generar un sitemaps.xml que se vaya actualizando automáticamente.
En la sección de estadísticas nos conectaremos a la API de Google Analytics para crear un dashboard de seguimiento de visitas.
Estas son las características técnicas generales, pero seguramente acabemos ampliándola una vez terminemos el proyecto. Cuando esté finalizada la versión 1.0, os dejaré una lista de cosas que habréis desarrollado hasta ese punto.