domain driven design - significado - ¿Es esto realmente DDD?
domain driven design tutorial (3)
Estoy seguro al 80% de que no debería estar haciendo esta pregunta porque podría parecer negativa y no quiero faltarle el respeto a nadie, especialmente al autor de este libro. He visto varias publicaciones que recomiendan este book y su project complementario. No he leído el libro, pero he pasado algunas horas hoy estudiando el proyecto. Y aunque parece muy completo, me está costando mucho saber cuán dispersos están los detalles de varias cosas. Estoy luchando en mis propios diseños con cuánto debo cambiar si una entidad cambia, y este proyecto no me hace sentir muy cómodo como solución.
Por ejemplo, hay un objeto Empleado que se hereda de una Persona. La persona tiene un constructor con nombre, apellido, etc. y, por lo tanto, también lo tiene Empleado. Private to Employee son miembros para el nombre, el apellido y las propiedades públicas del mismo.
Existe un EmployeeFactory que conoce tanto las propiedades Employee como Person, así como los nombres de columna SQL (para extraer valores de un lector).
Hay un EmployeeRepository con métodos no implementados PersistNewItem y PersistUpdatedItem que sospecho, si se implementa, compilaría SQL para las declaraciones INSERT y UPDATE como las que veo en CompanyRepository. Estos escriben las propiedades a las cadenas para construir el SQL.
Hay un PersonContract de ''Contrato de datos'' con los mismos miembros privados y propiedades públicas que Person, y un Contrato de empleado que se hereda de PersonContract como Employee does Person, con propiedades públicas que reflejan las entidades.
Existe una clase estática ''Convertidor'' con métodos estáticos que asignan entidades a Contratos, que incluyen
EmployeeContract ToEmployeeContract(Employee employee)
que copia los campos de uno a otro, incluidos los campos Person. Puede haber un método complementario que vaya por el otro lado, no estoy seguro.
Creo que también hay pruebas unitarias.
En total cuento de 5 a 10 clases, métodos y constructores con conocimiento detallado sobre las propiedades de la entidad. Quizás se generan automáticamente, no estoy seguro. Si tuviera que agregar un "Saludo" u otra propiedad a la Persona, ¿tendría que ajustar todas estas clases / métodos? Estoy seguro de que olvidaría algo.
Nuevamente, no quiero faltarle el respeto y este parece ser un ejemplo muy detallado y detallado para el libro. ¿Es así como se hace la DDD?
Domain Driven Design es muy simple. Dice: haz que tus clases de modelos reflejen el mundo real. Entonces, si tiene Empleados, tenga una clase de Empleado y asegúrese de que contenga las propiedades que le otorgan su ''Empleado-ness''.
La pregunta que hace no es sobre DDD, sino sobre la arquitectura de clase en general. Creo que tiene razón al cuestionar algunas de las decisiones sobre las clases que está viendo, pero no está relacionado específicamente con el DDD. Está más relacionado con los patrones de diseño de programación OOP en general.
La DDD es lo suficientemente nueva (al menos en algunos sentidos) para que sea un poco pronto para decir exactamente "cómo se hace". Sin embargo, la idea existe desde hace bastante tiempo, aunque no inventamos un nombre genial para eso.
En cualquier caso, la respuesta corta (IMAO) es "sí, pero ..." La idea de hacer un diseño basado en el dominio es modelar el dominio de manera muy explícita. Lo que está viendo es un modelo de dominio, es decir, un modelo orientado a objetos que describe el dominio del problema en el lenguaje del dominio del problema. La idea es que un modelo de dominio, ya que modela el "mundo real", es relativamente insensible al cambio y también tiende a localizar el cambio. Entonces, si, por ejemplo, su idea de lo que es un empleado cambia, tal vez agregando una dirección de correo y una dirección física, esos cambios serían relativamente localizados.
Sin embargo, una vez que tenga ese modelo, lo que mantengo son decisiones arquitectónicas que aún deben tomarse. Por ejemplo, tiene la capa de persistencia no implementada, que de hecho podría ser simplemente la construcción de SQL. También podría ser una capa de Hibernate, o utilizar el decapado de Python, o incluso ser algo salvaje como una estructura de tabla distribuida de Google AppEngine.
La cuestión es que esas decisiones se toman por separado y con otras razones que las decisiones de modelado de dominios.
Algo que he experimentado con un buen resultado es hacer el modelo de dominio en Python y luego construir un simulador con él en lugar de implementar el sistema final. Eso hace que el cliente pueda experimentar con algo, y también potencialmente le permite hacer estimaciones cuantitativas sobre lo que debe determinar la implementación final.
Para mí, lo que hace que DDD sea diferente del "mero" diseño basado en modelos es la noción de "raíces agregadas", es decir, una aplicación solo tiene permitido mantener referencias a las raíces agregadas , y en general solo tendrá un repositorio para la raíz agregada clase, no las clases que utiliza la raíz agregada
esto limpia el código considerablemente; la alternativa son los repositorios para cada clase de modelo, que es "simplemente" un diseño en capas, no DDD