Diseño Dirigido por Dominio con Aplicaciones Vue

Bienvenidos a esta charla sobre el diseño dirigido por dominio en la aplicación Vue.js. Mi nombre es Abdurazak Mostafa, también conocido como Geekmarrers. Soy un ingeniero frontend en Papershift. Soy un creador de contenido en YouTube donde publico videos sobre tutoriales de codificación, portadores de productividad y muchos otros. También puedes encontrarme en GitHub como Geekmarrers.

Hoy vamos a examinar el diseño dirigido por dominio, sus beneficios y cómo funciona con el diseño dirigido por dominio de Vue.js frente al modelo MVVM. También vamos a echar un vistazo rápido a un código simple basado en la estructura de una aplicación Vue.js escrita en un patrón de diseño dirigido por dominio.

Existen varios patrones de diseño que sabemos que existen en el ciclo de desarrollo de software. Tenemos el diseño orientado a objetos, tenemos el MVC, tenemos el DDD, y el MVVM, y muchos otros. Cuando miramos el OOD, que es el diseño orientado a objetos, que es un proceso de creación de un sistema de software o aplicación, utilizando el paradigma orientado a objetos, el MVC, que es el modelo Vue controladores, es un patrón de diseño utilizado para desarrollar interfaces de usuario que dividen la lógica de programa relacionada en tres elementos conectados, que son los modelos de Vue y el controlador, el MVVM, que son los modelos de Vue Vue modelo, que es algo así como el patrón para las aplicaciones de Vue.js, el patrón para las aplicaciones de Vue.js por defecto, que es un patrón que ayuda a separar limpiamente la lógica de negocio y presentación de una aplicación de su interfaz de usuario.

Todos sabemos que esto es una de las cosas en las que Vue.js prospera. El discurso principal del día es el diseño dirigido por dominio, que es un enfoque de diseño que se centra en modelar software para que coincida con un dominio según la entrada de los expertos en el dominio. Con esto, vamos a explicar más en las diapositivas.

Cuando miramos el DDD, que es el Diseño Dirigido por Dominio, es un enfoque para el desarrollo de software, que enfatiza en entender la lógica empresarial y modelar el dominio del problema. El objetivo es crear un dominio que refleje con precisión el lenguaje, los conceptos y las relaciones dentro del dominio, y esto a su vez ayuda al equipo a entender mejor las entidades empresariales complejas, lo que lleva a un mejor diseño de software y a la escritura de códigos mantenibles.

Cuando miramos la estructura del diseño dirigido por dominio en comparación con el MVVM predeterminado, el MVVM divide la estructura de la carpeta por relación con los aspectos funcionales de la base de code como el router, la tienda, las páginas, los componentes, los activos y muchas más carpetas personalizadas que queremos añadir a nuestra aplicación. Bueno, el enfoque DDD sigue un dominio en lugar de un MVVM suelto, lo que significa que nuestra aplicación está realmente desintegrada en los dominios centrales de nuestras aplicaciones. Y estos dominios, este dominio puede contener carpetas, y estas carpetas son como los modelos centrales en los que nuestras aplicaciones están utilizando, por lo que podrías tener un dominio de pagos, podrías tener como un dominio de productos, podrías tener un dominio de pedidos, podrías tener un perfil de usuario dominio, y muchas características dependiendo de los modelos o dominio de las aplicaciones que estamos construyendo.

Cuando miramos la estructura de carpetas predeterminada para el MVVM predeterminado, que es básicamente lo que obtendrías cuando generas la aplicación Vue.js, los activos, los componentes, los routers, las tiendas, las vistas. Con esto, si estás construyendo una aplicación más grande, podrías tener problemas cuando la aplicación se haga grande y aún si construyes con esta estructura predeterminada, podría ser difícil de mantener a largo plazo. ¿Verdad? Y esto es una de las cosas donde el diseño dirigido por dominio prospera. Y eso es porque para cada uno de nuestros dominios o para cada uno de nuestros modelos, va a tener su propio componente. Va a tener su propia tienda. Va a tener su propio router. Va a tener sus propias páginas y sus propias pruebas y muchas otras características personalizadas que podríamos querer añadir a nuestros varios dominios. Y con esto, es más limpio y más fácil de mantener a largo plazo.

Así que el beneficio de integrar el diseño dirigido por dominio a nuestra aplicación VGS es porque es una modelización más efectiva de dominios empresariales complejos. Es una base de code más estructurada y organizada que refleja la lógica del dominio. Es más mantenible, escalable y flexible en el desarrollo de aplicaciones de software. Es más efectivo en la construcción de interfaces de usuario. Creo que una de las cosas hermosas del DDD es que es para una fácil incorporación y propiedad de los productos dominados por los ingenieros dentro del equipo.

Entonces, ¿cuáles son los casos de uso para DDD con la aplicación VGS? Este patrón puede ser utilizado para construir aplicaciones de e-commerce con sistemas complejos de productos e inventario de gestión, aplicaciones financieras con modelos de data complejos y requisitos regulatorios. También puede ser utilizado en aplicaciones de atención médica con data de pacientes complejos y preocupaciones pervasivas y muchos otros dominios empresariales complejos en los que podemos incorporar el patrón DDD en nuestro software.

Así que vamos a echar un vistazo rápido a una base de código simple o a una estructura simple de cómo se puede implementar el DDD en una aplicación VGS. Voy a empezar con esto, con esta simple aplicación, y cuando miremos nuestra estructura de carpetas aquí, encontraremos que no es como el patrón regular de la cual la aplicación VGS tiene, que va a tener como, por defecto deberíamos ver las rutas, deberíamos ver la tienda, deberíamos ver los componentes y muchos otros. Porque esta aplicación ha sido convertida o el enfoque DDD ha sido implementado en esta aplicación simple, donde tenemos en nuestra fuente, tenemos una aplicación, tenemos una carpeta llamada el núcleo, que es como el modelo de la aplicación y es como la capa superior de nuestra aplicación, y en esa ruta vamos a tener nuestros modules, nuestros modules que son la parte central o los dominios centrales de nuestra aplicación. Y este simple ejemplo viene con solo dos dominios que son, o dos modules, que son solo el módulo de blog y el módulo de producto, y encontraremos aquí que para cada modelo es que tiene su propia API, sus propios componentes, sus propias constantes, sus propias páginas, sus propias rutas y su propia tienda. Y con esto, es bastante más fácil para nosotros ver la aplicación adaptada a un dominio particular y también asegurando que se cumplen la lógica empresarial y los requisitos empresariales. Y una de las cosas hermosas es que cuando miramos nuestro archivo de entrada, que es el main.js, encontraríamos una hermosa función de importación, que es la ruta de carga automática, que básicamente mira todos los dominios que tenemos, todos los modelos que tenemos en nuestra aplicación, obtiene la ruta, y luego podemos añadir esas rutas a nuestra aplicación en una escala más grande. Y cuando echamos un vistazo a esto en Así que solo voy a echar un vistazo a esto, veremos el dominio del producto, veremos el blog.

Entonces, esto es, básicamente, un detalle de un producto, un producto que proviene de la API ficticia. Correcto. Y también podemos pasar a la sección del blog. Y esto también es un blog que proviene de una API. Y también veremos en las herramientas de desarrollo que voy a recargar esto. Sí. También veremos que nuestra tienda está presente y también encontraremos que nuestras rutas en cada una de nuestras aplicaciones también están presentes. Y el segundo informe que les mostraré es de Philip Will. Philip Will pueden buscarlo en GitHub y seguirlo en Twitter. Vi un hermoso repositorio de Philip Will donde también hizo una implementación simple del diseño de mentoría en la aplicación VGS. Y al ver esto, también lo hizo con TypeScript, lo cual es bastante interesante y más seguro porque obviamente es TypeScript. Y una de las cosas más hermosas que vi en este enfoque es escribir un complemento que te ayuda a registrar, obtener las rutas y te ayuda a registrar las rutas. Te ayuda a registrar el módulo y también, si hay otros servicios en estos módulos o en estos dominios, también registra los servicios y registra y maneja los eventos y otras subentidades dentro de nuestra aplicación. Y cuando revisamos el archivo de entrada de esto, este complemento se utiliza para registrar los módulos, los servicios, las rutas y otras configuraciones que nuestra aplicación pueda tener. Y al igual que mencionamos en el repositorio anterior, también sigue la misma estructura de diseño orientado al dominio, que es que cada dominio tiene sus propios componentes, sus propios locales, sus propias páginas, sus propias rutas, sus propias tiendas. Y un enfoque similar para este subdominio, que son los dos dominios aquí, el ejemplo y los cuatro dominios. Y con esto, administrar una aplicación grande es mucho más fácil, escribir código mantenible está asegurado. Y una de las cosas más hermosas es la propiedad de estos dominios y es más fácil incorporar a nuevos miembros en un formulario más fácil. Es más fácil incorporar a nuevos miembros que se unen al equipo para comprender la estructura de la aplicación por dominios. Y sí, gracias por escuchar. Y espero que hayas aprendido una o dos cosas de esto y que intentes implementar el diseño orientado al dominio en tus propias aplicaciones VGS. Y otra cosa que podría agregar es que la estructura MVVM por defecto es bastante buena para una aplicación simple, no muy grande, no muy compleja. Pero a medida que comienzas a crecer o construir una aplicación más grande, o si sabes que el proyecto va a crecer definitivamente en las próximas semanas, meses o años, entonces es bueno comenzar tu aplicación con un patrón de diseño orientado al dominio desde el principio. Y eso es todo. Gracias por escuchar una vez más. Nos vemos en la próxima. Adiós.