API Rest et DDD

Concevez votre api rest indépendamment de la couche domaine.

L'un des concepts clés de la conception par domaine est couplage faible entre vos différentes couches logicielles. Ainsi, lorsque vous concevez votre api rest, vous pensez à la meilleure api rest que 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 concevoir votre api rest pour vous, parce que je ne sais pas ce que vous essayez de faire, mais voici quelques idées.

D'après ce que j'ai compris, vous avez une ressource de transaction. 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}.

alors, vous voulez "tenir" un marché. Je ne sais pas ce que cela signifie, Vous devez penser à ce qu'il change dans la ressource "Deal". Faut-il changer un attribut? si oui, alors vous modifiez simplement la ressource Deal.

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

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

est-ce que ça ajoute quelque chose? Pouvez-vous avoir plusieurs suspensions 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: oublier la théorie du repos. 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 le faire quelque chose de moche juste parce que c'est la norme.

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

Je ne peux pas concevoir votre api pour vous, vous êtes le seul à connaître vos cas d'utilisation, mais je vais répéter mes deux conseils:

• concevoir l'api rest par elle-même, puis utiliser la couche application pour appeler les objets de domaine appropriés le bon ordre. C'est exactement pour cela que la couche application est ici.
• ne suivez pas aveuglément les normes et les théories. Oui, vous devriez essayer de suivre les bonnes pratiques et les normes autant que possible, mais si vous ne pouvez pas les laisser derrière (après un examen attentif bien sûr)

je sépare les cas d'utilisation (UCs) en 2 groupes: commandes et requêtes (CQRS), et j'ai 2 contrôleurs REST (un pour les commandes et un autre pour les requêtes). Les ressources REST n'ont pas besoin d'être des objets modèles pour effectuer des opérations CRUDS sur eux à la suite de POST/GET/PUT/DELETE. Les ressources peuvent être tout objet que vous voulez. En effet dans DDD vous ne devriez pas exposer le modèle de domaine aux contrôleurs.

(1) RestApiCommandController: une méthode par cas d'utilisation de commande. reste la ressource dans L'URI est le nom de la classe de commande. La méthode est toujours POST, parce que vous créez la commande, et ensuite vous l'exécutez via un bus de commande (un médiateur dans mon cas). Le corps de la requête est un objet JSON qui permet de cartographier les propriétés de la commande (les args 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 cas d'utilisation de requête. Ici, la ressource REST dans L'URI est l'objet DTO que la requête retourne (comme l'élément d'une collection, ou juste un seul). La méthode est toujours GET, et les paramètres de la requête UC 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);
} 

NOTE: Mediator appartient à la couche application DDD. C'est la limite UC, il recherche la commande/requête, et exécute le service d'application approprié.