¿Qué significa el diseño impulsado por el dominio para las aplicaciones Javascript en el lado del cliente?
Quiero construir una aplicación basada en el enfoque ddd con javascript.
El marco que usaré para implementar la aplicación no es importante para mí porque quiero aprender a organizar el código de acuerdo con la arquitectura ddd.
Decidamos que el módulo es una carpeta.
Mi aplicación tiene inicio de sesión, notificaciones, informes, operaciones crud y cosas compartidas, y cada una de ellas tiene lógica de servidor API, componentes de interfaz de usuario, servicios y crud.
Por ejemplo, la carpeta de auth contiene lo siguiente
api --> server logic domain --> the domain itself. the bl: handle the data, use of http. feature-login --> the page itself containers of ui elements. feature-register --> the page itself containers of ui elements. ui --> ui elements for auth domain utils --> utils functions for auth domainLo mismo ocurre con la carpeta de notificación:
api --> server logic domain --> the domain itself. the bl: handle the data, use of http. feature-create --> the page itself containers of ui elements. feature-list --> the page itself containers of ui elements. ui --> ui elements for notification domain utils --> utils functions for notification domainY los informes:
api --> server logic domain --> the domain itself. the bl: handle the data, use of http. feature-dashboard --> the page itself containers of ui elements. feature-search --> the page itself containers of ui elements. feature-edit --> the page itself containers of ui elements. feature-view --> the page itself containers of ui elements. ui --> ui elements for report domain utils --> utils functions for report domainAsí es como construyo mi aplicación.
Entonces, ¿dónde está mi problema aquí?
Según ddd, el dominio no debe compartirse dentro de otros dominios. porque es crear desacoplamiento.
Pero en el dominio del informe necesito obtener al usuario del dominio de autenticación y necesito mostrar la notificación del dominio de notificación.
Esto hace que el desacoplamiento entre los dominios.
Entonces, ¿me lleva a darme cuenta de que tal vez no definí mi dominio correctamente? mi estructura de carpetas coincide con el principio ddd? si no, ¿cómo decido qué es dominio y qué no lo es?
DDD no dice que no se puede acceder a una entidad desde otra entidad.
Debe agrupar sus entidades por agregado e identificar el agregado raíz.
El agregado raíz se utilizará para acceder a las entidades.
La capa de presentación accederá al dominio a través de un servicio de aplicación.
El problema es que aquí estás haciendo un corte técnico y no un corte empresarial.
En DDD, antes de pasar a la fase de código utilizando patrones tácticos , existe una fase estratégica.
En esta fase estratégica, gracias a un experto en negocios, podrá utilizar los diferentes patrones estratégicos : lenguaje ubicuo , división e identificación de subdominios , estrategia en torno a Bounded Context .
Sin esta fase, haces lo que llamamos " DDD lite " y uno de los problemas ligados a esto es el que planteas.
Está bien haber separado su dominio de autenticación (la autenticación es casi siempre un subdominio genérico ), pero ¿por qué separó sus subdominios de notificación e informe? ¿Estás seguro de que esta es la decisión correcta?
Si quieres practicar sin un experto en negocios, ¿tal vez deberías hacer primero un mini Event Storming ?