Pregunta sobre modelos de dominio y su visibilidad

Question

Estuve involucrado en un debate interesante sobre la visibilidad de los modelos de dominio & me preguntaba si las personas aquí tienen alguna buena orientación.

• por mi comprensión de la MDA, no tenemos que exponemos el modelo de dominio a través de las capas de aplicación & niveles
• La razón es que cualquier cambio en el modelo de dominio tiene un impacto en la aplicación general
• La sabia Lo que se debe hacer es exponer objetos livianos (DTO) que son un pequeño subconjunto del modelo de dominio para abstraer el modelo real
• Por otro lado, cualquier cambio en el modelo de dominio significaría cambiar varias DTO a lo largo la aplicación para que el cambio sea visible, mientras que si exponemos el modelo de dominio, entonces t El cambio se encuentra en una sola ubicación

Espero ver algunos comentarios & pensamientos acerca de esto.

¡Apreciar toda la ayuda!

Answer 1

No, de eso no se trata la MDA. Se trata de aislarse de plataformas específicas, utilizando una notación de nivel superior (UML y su lenguaje de acción) para especificar el comportamiento del sistema.

Si debe exponer su modelo de dominio depende de la aplicación. Para los usuarios que usan la aplicación regularmente (piense en su IDE), entonces el modelo de dominio queda claramente expuesto, y usted manipula los objetos en ese dominio directamente. Pero para una aplicación que se usa ocasionalmente (piense en un kiosco en un aeropuerto para el check-in), entonces la aplicación debe guiar al usuario a través del flujo de trabajo.

Incluso si va a proteger los objetos de dominio, los DTO no son necesariamente necesarios; depende de si los objetos de dominio están en el mismo espacio de proceso que la capa que representa la UI. Las arquitecturas que requieren DTO no son muy buenas para adaptarse a los nuevos requisitos, ya que violan el principio DRY.

De hecho, es posible crear aplicaciones empresariales únicamente a partir de objetos de dominio directamente expuestos; este es el objetivo del patrón Objetos desnudos. Hay varios marcos de código abierto que implementan esto, incluido el marco de Objetos Desnudos original (en Java). También hay un equivalente comercial para .NET.

Para más discusión en general sobre objetos de dominio, le recomiendo que consulte el libro de Evans, Domain-Driven Design. También hay un grupo de noticias activo en Yahoo.

Dan

divulgación completa: Soy un confirmador a la NOF para Java, que no participan directamente en la versión .NET.

Answer 2

Estoy de acuerdo con Dan. Una forma de abordar esto es usar interfaces. Haces que tus métodos públicos devuelvan una interfaz que tus objetos de dominio implementan inicialmente. Cuando descubra que devolver los objetos de dominio de su aplicación ya no funciona, introduzca sus DTO e implemente la interfaz correspondiente. Mientras que las partes internas de su biblioteca ahora han cambiado, las aplicaciones consumidoras no se verán afectadas.

Answer 3

No estoy muy bien informado en esta área, pero recientemente leí blog post by Gojko Adzic que me parece relevante, acerca de cómo los DTO no son necesariamente una buena idea y que es correcto repetir el modelo de dominio en niveles separados, como no violar SECO.