Skip to content

Migrer vers le Event Sourcing, partie 3: les commandes

by Julien on juillet 22nd, 2010

An english version of this post is available here.

Vue d’ensemble

Cette refactorisation est plus subtile que la précédente. Dans la partie 1, j’ai déjà expliqué qu’il était important d’avoir une méthode de racine d’agrégat par cas d’utilisation. Nous allons maintenant faire un pas de plus en créant une classe pour chacun de ces cas, sous forme de commandes:

Avantages

Isolation

L’interface utilisateur n’a maintenant plus de dépendance sur le modèle de domaine. Les deux peuvent évoluer séparément sans s’impacter mutuellement.

Communication

Créer des classes pour les commande, c’est aussi reconnaître que ces dernières sont une partie importante du modèle de domaine et du “Ubiquitous Language”. Souvent, les utilisateurs vont parler assez simplement de ce qu’ils attendent de l’application:

  • Je veux créer des étudiants.
  • Je veux créer des classes.
  • Je veux inscrire des étudiants dans des classes.

Les commandes vont formaliser ces besoins.

Nouvelles opportunités

Avoir en main les commandes dans le système ouvre certaines opportunités. D’abord, il devient très facile de logguer les commandes. En faisant cela, vous captureriez tout ce que les utilisateurs ont voulu modifier dans l’application.
Le découplage entre l’exécution de la commande et l’interface utilisateur ouvre aussi des choix. Dans l’exemple de ce post, les commandes sont exécutées immédiatement, dans le thread du contrôleur. Mais il serait facile d’en déléguer l’exécution sur un serveur applicatif (par exemple en utilisant NServiceBus ). Cela permet de décharger vos serveurs web et de monter en charge plus facilement à coût très faible. De plus, vous n’avez pas besoin de faire ce choix maintenant. Il ne coûtera pas plus cher lorsque vous en aurez besoin.

Implémentation

Ce qui a changé

Il y a 2 nouveaux projets dans la solution:

Le premier contient les commandes, et l’autre les gestionnaires de commandes. Un gestionnaire de commande est responsable d’appeler la racine d’agrégat appropriée pour traiter la commande.

Les commandes sont dispatchées à leur gestionnaires par un bus.

Envoyer une commande

Au final, le code du contrôleur devient encore plus simple:

public RedirectToRouteResult DoCorrectName(StudentDTO model)
{
    var cmd = new CorrectStudentNameCommand(model.Id, model.FirstName, model.LastName);
    commandBus.Send(cmd);

    return RedirectToRoute(new
    {
        controller = "Student",
        action = "Index"
    });
}

Le bus va simplement transmettre la commande à la méthode correspondante dans le gestionnaire:

public void Handle(CorrectStudentNameCommand cmd)
{
    var student = studentRepository.ById(cmd.StudentId);

    if (student != null)
    {
        student.CorrectName(cmd.FirstName, cmd.LastName);
    }
}

Conseils

Les conseils de la partie 1 s’appliquent aussi ici:

  • Une commande ne doit s’applique qu’à une racine d’agrégat.
  • Une seule méthode d’agrégat doit être appelée pour traiter une commande.

Démarrer l’application exemple

Les sources pour toute la série de billets sont disponible sur GitHub à http://github.com/jletroui/TransitioningToEventSourcing
.

Vous aurez simplement besoin de créer une base de données vide intitulée “DDDPart3″ dans SQLExpress avant de lancer l’application.

Liste des billets “migrer vers le Event Sourcing”:

From → Event Sourcing

12 Comments
  1. Perhaps a better way to conceptualise the domain when you’re talking about communication benefits is this:

    I want to enroll students.
    I want to create classes.
    I want to register students to classes.

    Instead of ‘creating’ students, ‘enrolling’ them seems to make more domain sense.

    I’m still struggling to move away from a CRUD mentality.

  2. Julien permalink

    scceroos, you are right. We should never “create” a person in software. Mothers do that alone. Even for the classes, “I want to declare classes” might be more appropriate. Actually, most of the time, the business has already better terms for such operations. Listening to your business expert is a great part of DDD.

  3. malicksarr@gmail.com permalink

    Bonjour,

    Juste pour un encouragement. Sympa de vulgariser le DDD. Grâce à votre article, j’ai progressé dans ma compréhension de la mise en oeuvre des principes du DDD.

    Merci encore !

  4. Hey just wanted to give you a quick heads up and
    let you know a few of the pictures aren’t loading correctly.
    I’m not sure why but I think its a linking issue.
    I’ve tried it in two different internet browsers and both show the
    same outcome.

Trackbacks & Pingbacks

  1. Transitioning to Event Sourcing, part 1: the DDD “light” application | Julien's blog
  2. Transitioning to Event Sourcing, part 2: go CQRS with DTOs | Julien's blog
  3. Transitioning your DDD “light” application to CQRS and Event Sourcing | Julien's blog
  4. Transitioning to Event Sourcing, part 4: track state changes | Julien's blog
  5. Julien Letrouit on Transitioning Brownfield Apps « CQRS
  6. Transitioning to Event Sourcing, part 5: use events for updating your domain database | Julien's blog
  7. Transitioning to Event Sourcing, part 6: store events | Julien's blog
  8. Transitioning to Event Sourcing, part 7: build a view model | Julien's blog

Leave a Reply

Note: XHTML is allowed. Your email address will never be published.

Subscribe to this comment feed via RSS