Je travaille sur un projet dans lequel nous essayons d'appliquer à la fois une conception orientée domaine et REST à une architecture orientée service. Nous ne nous inquiétons pas de la conformité 100% REST; il serait probablement préférable de dire que nous essayons de créer des API HTTP orientées ressources (~ niveau 2 du modèle de maturité REST de Richardson). Néanmoins, nous essayons d'éviter l'utilisation de requêtes HTTP de type RPC, c'est-à-dire que nous essayons d'implémenter nos verbes HTTP conformément à la norme RFC2616 plutôt que d'utiliser la méthode POST
à faire IsPostalAddressValid(...)
, par exemple.
Cependant, mettre l'accent sur cela semble se faire aux dépens de notre tentative d'appliquer une conception pilotée par domaine. Avec seulement GET
, POST
, PUT
, DELETE
et quelques autres méthodes rarement utilisées, nous avons tendance à construire des services Cruddy et services Cruddy ont tendance à avoir des modèles anémiques de domaine.
POST
: Recevoir les données, les valider, les transférer dans les données. GET
: Récupérer les données, les renvoyer. Pas de vraie logique métier là-bas. Nous utilisons également des messages (événements) entre les services, et il me semble que l'essentiel de la logique métier finit par être construit autour de cela.
REST et DDD sont-ils en tension à un certain niveau? (Ou est-ce que je comprends mal quelque chose ici? Peut-être faisons-nous autre chose de mal?) Est-il possible de construire un modèle de domaine fort dans une architecture orientée service tout en évitant les appels HTTP de type RPC?
IsPostalAddressValid(...)
pourrait s’insérer dans "Fournir un bloc de données, tel que le résultat de la soumission d’un formulaire, à un processus de traitement de données"?