Interfaz con capa de servicio o dominio objetos mismos? (DDD)

Question

Todavía estoy aprendiendo sobre DDD y tengo estas dos preguntas (probablemente simples):

Si un fábrica crea nuevo objeto / gráfico / casos agregados, pero también "Reconstituye" objetos / gráficos de la Repositorio , entonces:

(1) ¿Su funciones de la capa de servicios / trabajos / tareas / llamada en la fábrica o un método de comportamiento en la instancia de la entidad o de una función DomainService de unidad de trabajo? Estoy perdido en cuanto a la pila de llamadas basado en la responsabilidad de estos componentes.

(2) casos Do entidad, incluso tienen "los métodos de comportamiento", como más arriba? Por ejemplo hace un Post han p.UpdatePost(string bodyText) o es que no es una preocupación del modelo de dominio y por lo mismo debe lograrse con el repositorio? O la función de la capa de servicio, en caso de que sea llamando al repositorio en este caso y la instancia de la entidad simplemente tener métodos de comportamiento que son específicos para el dominio y no la persistencia? Pero entonces, ¿por qué suena "actualizar un post" es una función de dominio cuando eso es el objetivo del usuario?

Se puede ver que estoy por todo el lugar. Por favor, ayuda.

Answer 1

  

(1) ¿Su funciones de la capa de servicios / trabajos / tareas / llamada en la fábrica o un método de comportamiento en la instancia de la entidad o de una función DomainService de unidad de trabajo? Estoy perdido en cuanto a la pila de llamadas basado en la responsabilidad de estos componentes.

Por lo general, - nivel superior recupera raíz agregada necesaria y llama a una función en él. A veces, nivel superior recupera raíces múltiples agregados y pasarlos a un servicio de dominio, pero no a menudo porque el servicio de dominio es una señal muy fuerte de que existe raíz agregada no reconocido. Al final - nivel superior asegura raíz agregado se mantuvo

.

  

(2) casos Do entidad, incluso tienen "los métodos de comportamiento", como más arriba? Por ejemplo no tiene un Post p.UpdatePost (bodyText cadena) o es que no es una preocupación del modelo de dominio y por lo mismo debe lograrse con el repositorio? O la función de la capa de servicio, en caso de que sea llamando al repositorio en este caso y la instancia de la entidad simplemente tener métodos de comportamiento que son específicos para el dominio y no la persistencia? Pero entonces, ¿por qué suena "actualizar un post" es una función de dominio cuando eso es el objetivo del usuario?

Sí, lo hacen. modelo de dominio debe ser consciente de ello de los cambios de estado. Y eso es mucho más beneficioso, ya que parece en un principio. Lo bueno de esto es que Usted gana puntos extensibilidad. Si el cliente caminará semana más tarde para usted y decir que quiere que el sistema para comprobar las cosas adicionales cuando las actualizaciones de Usuario Nota - en lugar de buscar cada línea de post.bodyText="new value", usted será capaz de ir directamente al método post.UpdatePost y adjuntar cosas necesarias no

Por otro lado - ABM no es mutuamente excluyente con el diseño de dominio impulsada. P.ej. - en mi solicitud, gestión de usuarios y sus roles es lo suficientemente interesante que ni siquiera estoy tratando de modelar de forma granular. Es necesario reconocer partes lo que importa en los negocios Su aplicación está describiendo y trabajar con.

Tenga en cuenta que el diseño de dominio impulsada sólo tiene sentido para aplicaciones complejas. La simple aplicación del blog no lo necesita.

  

(3) ¿Me equivoco al suponer que una capa de servicio (no los servicios de dominio) debe encapsular cómo un interactúa con la capa de interfaz de dominio?

A mi entender - servicios de aplicaciones son más para la orquestación de la infraestructura. Si no existe una infraestructura implicados - a continuación, servicios de aplicaciones pierde valor :

  

Los servicios de aplicaciones, básicamente, son sólo fachadas. Y cada fachada es malo si la complejidad que añade sobreponderaciones problemas de los que resuelve.

---

Dentro de dominio:

//aggregate root is persistence ignorant. 
//it shouldn't reference repository directly
public class Customer{
  public string Name {get; private set;}
  public static Customer Register(string name){
    return new Customer(name);
  }
  protected Customer(string name){
    //here it's aware of state changes.
    //aggregate root changes it's own state
    //instead of having state changed from outside
    //through public properties
    this.Name=name;
  }
}

//domain model contains abstraction of persistence
public interface ICustomerRepository{
  void Save(Customer customer);
}

Fuera del dominio:

public class CustomerRepository:ICustomerRepository{
  //here we actually save state of customer into database/cloud/xml/whatever
  public void Save(Customer customer){
    //note that we do not change state of customer, we just persist it here
    _voodoo.StoreItSomehow(customer);
  }
}

//asp.net mvc controller
public class CustomerController{
  public CustomerController(ICustomerRepository repository){
    if (repository==null)throw new ArgumentNullException();
    _repository=repository;
  }
  public ActionResult Register(string name){
    var customer=Customer.Register(name);
    _repository.Save(customer);
  }
}