Interface avec couche de service ou d'un domaine eux-mêmes des objets? (DDD)

Question

Je suis encore à apprendre à propos de DDD et j'ai ces deux questions (probablement simple):

Si un usine crée nouvel objet / graphique / instances globales , mais aussi "reconstitue" objets / graphiques de la référentiel , puis:

(1) Est-ce que votre couche de service fonctions / emplois / tâches / unité de travail dans l'appel d'usine ou d'une méthode comportementale sur l'instance d'entité ou une fonction DomainService? Je suis perdu à la pile d'appel en fonction de la responsabilité de ces composants.

(2) instances Do entité ont même "méthodes comportementales" comme ci-dessus? Par exemple un message n'ont p.UpdatePost(string bodyText) ou est-ce pas une préoccupation du modèle de domaine et donc le même doit être réalisé avec le référentiel? Ou la fonction de couche de service, doit-il appeler le référentiel dans ce cas et l'instance de l'entité ont simplement des méthodes comportementales qui sont spécifiques au domaine et non la persistance? Mais alors, pourquoi ça sonne comme « la mise à jour d'un poste » est une fonction de domaine lorsque c'est l'objectif de l'utilisateur?

Vous pouvez voir que je suis partout. S'il vous plaît aider.

Answer 1

  

(1) Est-ce que votre couche de service fonctions / emplois / tâches / unité de travail dans l'appel d'usine ou d'une méthode comportementale sur l'instance d'entité ou une fonction DomainService? Je suis perdu à la pile d'appel en fonction de la responsabilité de ces composants.

En général - niveau supérieur récupère la racine globale nécessaire et appelle ensuite une fonction. Parfois, niveau supérieur récupère les racines multiples et les agrégats passer au service de domaine, mais pas souvent parce que le service de domaine est un signe assez fort qu'il ya racine globale non reconnue. A la fin - haut niveau assure la racine globale est conservée

.

  

(2) instances Do entité ont même "méthodes comportementales" comme ci-dessus? Par exemple un message n'ont p.UpdatePost (string bodyText) ou est-ce pas une préoccupation du modèle de domaine et donc le même doit être réalisé avec le référentiel? Ou la fonction de couche de service, doit-il appeler le référentiel dans ce cas et l'instance de l'entité ont simplement des méthodes comportementales qui sont spécifiques au domaine et non la persistance? Mais alors, pourquoi ça sonne comme « la mise à jour d'un poste » est une fonction de domaine lorsque c'est l'objectif de l'utilisateur?

Oui, ils le font. modèle de domaine doit être conscient de changements d'état. Et c'est beaucoup plus bénéfique car il semble au premier abord. Grande chose à ce sujet est que vous gagnez point d'extension. Si le client marcheront semaine plus tard pour vous dire qu'il veut système pour vérifier les choses supplémentaires lors des mises à jour de l'utilisateur après - au lieu de rechercher toutes les lignes de post.bodyText="new value", vous pourrez aller directement à la méthode de post.UpdatePost et attacher les choses nécessaires il y a

Par contre - CRUD ne sont pas mutuellement exclusifs avec un design axé sur le domaine. Par exemple. - dans mon application, la gestion des utilisateurs et de leurs rôles est assez sans intérêt que je ne vais même pas essayer de le modèle granulairement. Vous devez reconnaître des parties ce qui compte dans les affaires Votre demande est décrit et travailler avec.

Gardez à l'esprit que la conception Domain Driven n'a de sens que pour les applications complexes. application simple blog n'a pas besoin.

  

(3) Ai-je tort de supposer qu'une couche de service (non Domain Services) devrait résumer comment une interagit interface avec la couche de domaine?

Comme je le vois - les services d'application sont plus pour l'infrastructure orchestrer. S'il n'y a pas d'infrastructure impliquée - alors le service d'application perd de sa valeur :

  

services d'application sont essentiellement des façades. Et chaque façade est mauvaise si elle ajoute de la complexité des problèmes de ce résoud-pondération.

---

Domaine intérieur:

//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);
}

En dehors du domaine:

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);
  }
}