API Rest y DDD

Diseñe su api rest independientemente de la capa de dominio.

Uno de los conceptos clave del diseño impulsado por dominio es acoplamiento bajo entre sus diferentes capas de software. Por lo tanto, cuando diseñas tu api rest, piensas en la mejor api rest que podrías tener. Luego, es la función de la capa de aplicación llamar a los objetos de dominio para realizar el caso de uso requerido.

No puedo diseñar su api rest para usted, porque no se lo que está tratando de hacer, pero aquí hay algunos idea.

Según lo entiendo, usted tiene un recurso de Acuerdo. Como usted ha dicho, la creación / eliminación son fáciles:

• POST / rest / {version} / deals
• DELETE /rest/{version}/deals/{id}.

Entonces, quieres "mantener" un trato. No se lo que eso significa, tienes que pensar en lo que cambia en el recurso "Deal". ¿Cambia un atributo? si es así, entonces simplemente estás modificando el recurso de Negocio.

PUT / rest / {version}/deals/{id}

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

Lo hace añadir algo? ¿Puedes tener varias retenciones en un Trato? Me suena que "hold" es un sustantivo. Si es feo, busca un sustantivo mejor.

POST / rest/{version}/deals/{id} / holds

{
    reason: "something"
}

Otra solución: olvidar la teoría del DESCANSO. Si crees que tu api sería más clara, más eficiente, más simple con el uso de verbos en la url, entonces por todos los medios, hazlo. Probablemente puedas encontrar una manera de evitarlo, pero si no puedes, no hagas algo feo solo porque es la norma.

Mira twitter api: muchos desarrolladores dicen que twitter tiene una API bien diseñada. ¡Tadaa, usa verbos! ¿A quién le importa, siempre y cuando sea genial y fácil de usar?

No puedo diseñar su api para usted, usted es el único que conoce sus casos de uso, pero diré de nuevo mis dos consejos:

• Diseñe la api rest por sí misma y luego use la capa de aplicación para llamar a los objetos de dominio apropiados en el orden correcto. Eso es exactamente para lo que está aquí la capa de aplicación.
• No sigas la normas y teorías ciegamente. Sí, debe tratar de seguir las buenas prácticas y normas tanto como sea posible, pero si no puede dejarlas atrás (después de una cuidadosa consideración, por supuesto)

Separo los casos de uso (UCs) en 2 grupos: comandos y consultas (CQRS), y tengo 2 controladores REST (uno para comandos y otro para consultas). Los recursos REST no tienen que ser objetos modelo para realizar operaciones CRUD en ellos como resultado de POST/GET/PUT/DELETE. Los recursos pueden ser cualquier objeto que desee. De hecho, en DDD no debe exponer el modelo de dominio a los controladores.

(1) RestApiCommandController: Un método por caso de uso de comando. El recurso RESTO en el URI es el nombre de la clase de comando. El método siempre es POST, porque creas el comando, y luego lo ejecutas a través de un bus de comandos (un mediador en mi caso). El cuerpo de la solicitud es un objeto JSON que asigna las propiedades del comando (los args del UC).

Por ejemplo: 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: Un método por caso de uso de consulta. Aquí el recurso REST en el URI es el objeto DTO que devuelve la consulta (como el elemento de una colección, o solo). El método es siempre GET, y los parámetros de la consulta UC son parámetros en el URI.

Por ejemplo: 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);
} 

NOTA: Mediator pertenece a la capa de aplicación DDD. Es el límite de UC, busca el comando / consulta y ejecuta el servicio de aplicación apropiado.