API Rest et DDD

De la conception de votre api rest indépendamment de la couche domaine.

L'un des concepts clés de domain driven design est de couplage faible entre les différentes couches logicielles. Ainsi, lors de la conception de votre api rest, vous réfléchissez à la meilleure api rest vous pourriez avoir. Puis, c'est le rôle de la couche application pour appeler les objets du domaine pour effectuer les cas d'utilisation.

Je ne peux pas le concevoir votre api rest pour vous, parce que je ne sais pas ce que vous essayez de faire, mais voici quelques idées.

Si je comprends bien, vous avez un Deal de ressources. Comme vous l'avez dit, la création/suppression sont faciles :

• POST /le reste/{version}/offres spéciales d'
• SUPPRIMER /le reste/{version}/offres/{id}.

Ensuite, vous voulez pour "tenir" une affaire. Je ne sais pas ce que cela signifie, vous avez à penser à ce que cela change dans la ressource "Deal". Faut-il changer un attribut? si oui, alors vous êtes tout simplement la modification de l'accord de la ressource.

METTRE /le reste/{version}/offres/{id}

{
    ...
    held: true,
    holdReason: "something",
    ...
}

- T-il quelque chose? Vous pouvez avoir plusieurs tient sur une Affaire? Me semble que "hold" est un substantif. Si c'est moche, trouver un meilleur nom.

POST /le reste/{version}/offres/{id}/contient

{
    reason: "something"
}

une autre solution: oubliez RESTE de la théorie. Si vous pensez que votre api serait plus clair, plus efficace, plus simple avec l'utilisation de verbes dans l'url, puis par tous les moyens, de le faire. Vous pouvez probablement trouver un moyen de l'éviter, mais si vous ne pouvez pas, ne pas faire quelque chose de moche juste parce que c'est la norme.

Regarder l'api twitter: beaucoup de développeurs disent que twitter a ainsi conçu une API. Tadaa, il utilise des verbes! On s'en fout, tant que c'est cool et facile à utiliser?

Je ne peux pas le concevoir votre api pour vous, vous êtes le seul qui sait votre cas d'utilisation, mais je vais le dire encore une fois mes deux conseils:

• Conception de l'api reste par lui-même, et ensuite utiliser la couche d'application pour appeler les objets de domaine dans l'ordre. C'est exactement ce que la couche application est là pour vous.
• Ne respectent pas les normes et les théories à l'aveuglette. Oui, vous devriez essayer de respecter les bonnes pratiques et les normes autant que possible, mais si vous ne pouvez pas les laisser derrière (après un examen attentif de cours)

J'ai séparé les cas d'utilisation (UCs) en 2 groupes: les commandes et les requêtes (CQRS), et j'ai 2 manettes (une pour les commandes et l'autre pour les requêtes). Le RESTE des ressources n'ont pas à être les objets de modèle pour effectuer des opérations CRUD sur eux comme un résultat de POST/GET/PUT/DELETE. Les ressources peuvent être n'importe quel objet que vous voulez. En effet, en DDD vous ne devriez pas vous exposer modèle de domaine pour les contrôleurs.

(1) RestApiCommandController: Une méthode par commande de cas d'utilisation. Le RESTE des ressources dans l'URI est la commande nom de la classe. La méthode est toujours la POSTE, parce que vous créez la commande, et puis vous exécutez à travers un bus de commande (un médiateur dans mon cas). Le corps de la requête est un objet JSON qui mappe les propriétés de la commande (les arguments de l'UC).

Par exemple: http://localhost:8181/command/asignTaskCommand/

@RestController
@RequestMapping("/command")
public class RestApiCommandController {

private final Mediator mediator;    

@Autowired
public RestApiCommandController (Mediator mediator) {
    this.mediator = mediator;
}    

@RequestMapping(value = "/asignTaskCommand/", method = RequestMethod.POST)
public ResponseEntity<?> asignTask ( @RequestBody AsignTaskCommand asignTaskCommand ) {     
    this.mediator.execute ( asigTaskCommand );
    return new ResponseEntity ( HttpStatus.OK );
}

(2) RestApiQueryController: Une méthode par requête cas d'utilisation. Voici le RESTE des ressources dans l'URI est la DTO de l'objet retourné par la requête (en tant qu'élément d'une collection, ou juste un seul). La méthode est toujours d'OBTENIR, et les paramètres de la requête de communications UNIFIÉES sont params dans l'URI.

Par exemple: http://localhost:8181/query/asignedTask/1

@RestController
@RequestMapping("/query")
public class RestApiQueryController {

private final Mediator mediator;    

@Autowired
public RestApiQueryController (Mediator mediator) {
    this.mediator = mediator;
}    

@RequestMapping(value = "/asignedTask/{employeeId}", method = RequestMethod.GET)
public ResponseEntity<List<AsignedTask>> asignedTasksToEmployee ( @PathVariable("employeeId") String employeeId ) {

    AsignedTasksQuery asignedTasksQuery = new AsignedTasksQuery ( employeeId);
    List<AsignedTask> result = mediator.executeQuery ( asignedTasksQuery );
    if ( result==null || result.isEmpty() ) {
        return new ResponseEntity ( HttpStatus.NOT_FOUND );
    }
    return new ResponseEntity<List<AsignedTask>>(result, HttpStatus.OK);
} 

REMARQUE: Médiateur appartient à la DDD de la couche application. C'est l'UC limite, il recherche la commande/de requête, et d'exécuter les cas de demande de service.