Conceptos DDD en el desarrollo de la capa N

Question

Después de pasar un par de meses estudiando la metodología DDD, ahora comencé a aplicar estos conceptos en productos reales en mi empresa. De hecho, he tenido la tarea de crear una arquitectura adecuada y mantenible para el desarrollo futuro.

Hemos decidido utilizar las siguientes tecnologías: EF4 (realmente V2), Unity

La cantidad de información que he obtenido ha sido más esclarecedora, sin embargo, me quedan varias preguntas en las mejores prácticas:

Pregunta 1: DTOS - Mejores prácticas

Tengo mis objetos de dominio (clases POCO). Hay varias formas de implementar estas clases.

1. Enfoque tradicional: cree clases de POCO que contengan getters/setters públicos, validación y lógica comercial apropiada. También cree DTO y use técnicas de mapeo para administrarlas. (Autómero)
2. Tradicional - DTO: cree clases POCO como se indicó anteriormente, sin embargo, use sus POCOS como objetos de transferencia. Sin embargo, entiendo que los objetos comerciales nunca deberían dejar el dominio.
3. Híbrido: me topé con un interesante entrada en el blog en el que el autor crea sus objetos POCO y DTO. Dentro de su objeto de dominio, crea una instancia del DTO. Esto permite una mantenibilidad más fácil, ya que no está duplicando sus propiedades como en el #1. Al igual que:

public abstract class POCOBase<T> : ValidationBase, IPOCO where T : DTOBase, new()
{

 public T Data { get; set; }

 public POCOBase()
 {
     Data = new T();
 }

 public POCOBase(T dto)
 {
     Data = dto;
 }
  }

  public class SomePOCO : POCOBase { }

  public class SomeDTO : DTOBase

  {

 public String Name { get; set; }

 public String Description { get; set; }

 public Boolean IsEnabled { get; set; }
}


// EXAMPLES
// POCOBase<SomeDTO> somePOCO = new SomePOCO();
// somePOCO.Data.Name = "blablabla";
// somePOCO.Validate();
// return somePOCO.Data;

Pregunta 2: ¿Qué objetos deben devolver la capa de UI/Servicio?

Este es el objetivo del DTO. Un objeto muy simple y liviano que contiene solo los atributos desnudos. Tampoco contiene ningún resultado de validación en él. Si estoy serializando mis DTO al cliente, se debe suponer que el cliente necesita resultados de validación como una colección Invalidrules.

Por ejemplo, digamos que estoy trabajando con la API de Amazon. Me gustaría agregar un libro a mi tienda personal. Si intento agregar un libro sin enviar su ISBN, el servicio probablemente devolvería algún tipo de grupo de respuesta que contenga errores de resultados de validación.

¿Me estoy perdiendo de algo? Tenía la impresión (al menos de DDD "puristas") de que los DTO no deberían contener lógica comercial. Me parece que los DTO no proporcionan suficiente información como objetos de transferencia. O eso o necesito un nuevo tipo de objeto de respuesta que encapsula los resultados de DTO y validación.

Pregunta 3: ¿Cuánto COI es demasiado?

Me parece evidente que debería seguir la regla de oro:

"Identifique las partes de la aplicación que varían y se separan de las que permanecen igual".

Para mí esto tiene sentido en términos de aplicar el COI. Para reducir las dependencias, mi presentación, la lógica comercial y las capas de acceso a datos se comunican a través de un contenedor de COI. Mi capa de aplicación contiene interfaces y abstracciones comunes. Parece exagerado usar el COI mucho más que esto. Me encanta el hecho de que puedo crear repositorios de pruebas simuladas, y simplemente cambiando la configuración de Unity, puedo hacer uso de TDD.

Espero haber declarado claramente estas preguntas. ¡Gracias por su ayuda de antemano!

Answer 1

Intentaré abordar sus preguntas una a la vez.

respuesta 1

Los DTO son ortogonales a DDD porque tienen un propósito diferente en un lugar diferente en la arquitectura de una aplicación. Dicho esto, los DTO no tienen lugar en un modelo de dominio porque no tienen comportamiento y, por lo tanto, conducirán a Modelos de dominio anémico.

POCOS con persistencia de ignorancia es el camino a seguir. Jeremy Miller tiene un buen artículo que explica este concepto.

Respuesta 2

Las capas que se encuentran en la parte superior del modelo de dominio a menudo necesitarán devolver sus propios objetos que se adaptan a los fines en cuestión.

Para UI, el patrón MVVM funciona particularmente bien. Este artículo Presenta MVVM para WPF, pero el patrón también funciona como un encanto en ASP.NET MVC.

Para los servicios web, aquí es donde se aplica el patrón DTO. Los contratos de datos de WCF son DTO, en caso de que se lo pregunte :)

Esto requerirá mucho mapeo que vaya y viene entre la interfaz de servicio y el modelo de dominio, pero ese es el precio que debe pagar por el diseño flexible. Puedes encontrar Autófano útil a este respecto.

Respuesta 3

Cuanto más IOC (realmente: DI), mejor, pero una cosa sobre su pregunta me sorprendió: un contenedor DI solo debe conectar el gráfico de objetos y luego salir del camino. Los objetos no deben confiar en el contenedor DI.

Ver esta tan respuesta para más detalles.