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.
