¿Es esto realmente DDD?

Question

Estoy 80% seguro de que no debería hacer esta pregunta porque podría parecer negativa y no faltarle el respeto a nadie, especialmente al autor de este libro. He visto varias publicaciones que recomiendan book y su compañero project. No he leído el libro, pero hoy he pasado unas horas estudiando el proyecto. Y si bien se ve muy completo, estoy teniendo un momento muy difícil con la cantidad de detalles de varias cosas dispersas. Estoy luchando en mis propios diseños con cuánto tengo que 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 hereda de una Persona. La persona tiene un constructor con primer nombre, apellido, etc. y, por lo tanto, también lo hace Employee. Privado para el empleado son miembros para el primer nombre, apellido, más propiedades públicas para el mismo.

Hay una EmployeeFactory que conoce tanto las propiedades del empleado como de la persona, así como los nombres de las columnas SQL (para extraer valores de un lector).

Hay un EmployeeRepository con métodos PersistNewItem y PersistUpdatedItem no implementados que sospecho que, si se implementara, construiría SQL para las sentencias INSERT y UPDATE como veo en CompanyRepository. Estos escriben las propiedades de 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 EmployeeContract que hereda de PersonContract como Employee Does Person, con propiedades públicas que reflejan las entidades.

hay una clase estática 'convertidor' con métodos estáticos que se asignan a las entidades contratos, incluyendo

EmployeeContract ToEmployeeContract(Employee employee) 

que copia los campos de la una a la otra persona, incluidos los campos. 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 5-10 clases, métodos y constructores con conocimiento detallado sobre las propiedades de la entidad. Tal vez se generen automáticamente, no estoy seguro. Si tuviera que agregar un 'Saludo' u otra propiedad a Persona, ¿tendría que ajustar todas estas clases/métodos? Estoy seguro de que me olvidaré de algo.

Una vez más, me refiero sin falta de respeto y este parece ser un ejemplo muy completo y detallado para el libro. ¿Es así como se hace DDD?

Answer 1

DDD es lo suficientemente nuevo (al menos en algunos sentidos) que puede ser un poco pronto para decir exactamente "cómo se hace". Sin embargo, la idea ha existido durante mucho tiempo, aunque no hemos inventado un buen nombre para ella.

En cualquier caso, la respuesta corta (IMAO) es "sí, pero ..." La idea de hacer un diseño de 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 idioma 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. Por lo tanto, si, por ejemplo, tu idea de lo que es un empleado cambia, tal vez agregando una dirección postal así como una dirección física, entonces esos cambios estarían relativamente localizados.

Una vez que tiene ese modelo, sin embargo, tiene lo que mantengo son las decisiones arquitectónicas que aún deben tomarse. Por ejemplo, tiene la capa de persistencia no implementada, que de hecho puede ser simplemente la construcción de SQL.También podría ser una capa de Hibernate, o usar decapado de Python, o incluso ser algo salvaje como una estructura de tabla distribuida de Google AppEngine.

El hecho es que esas decisiones se toman por separado, y con otras razones, que las decisiones de modelado del dominio.

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 lo convierte en algo con lo que el cliente puede experimentar, y también potencialmente le permite hacer estimaciones cuantitativas sobre las cosas que la implementación final debe determinar.

Answer 2

Domain Driven Design es realmente simple. Dice: haz que tus clases Model reflejen el mundo real. Por lo tanto, si tiene Empleados, tenga una clase Empleado y asegúrese de que contenga las propiedades que le dan su 'Empleado'.

La pregunta que hace NO es sobre DDD, sino sobre la arquitectura de clases 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 DDD. Está más relacionado con los patrones de diseño de programación OOP en general.

Answer 3

a mí, lo que hace que DDD diferente de "mero" diseño basado en modelos es la noción de "raíces agregados", es decir, una aplicación se sólo se permite para mantener las referencias a las raíces agregadas, y en general sólo se tendrá un repositorio para la clase de raíz agregada, no las clases que utiliza la raíz agregada

Esto limpia el código considerablemente; la alternativa son repositorios para cada clase de modelo, que es "meramente" un diseño en capas, no DDD