J'étudie la propreté et, par conséquent, je repense de façon spectaculaire la façon dont je conçois et écris les logiciels.
Cependant, je suis encore aux prises avec des règles commerciales telles que "lors de l'enregistrement des mises à jour d'un élément, chargez d'abord toute la liste des éléments que j'ai la permission d'afficher / modifier, etc., confirmez que cet élément est dans la liste, et que la catégorie d'élément n'est pas verrouillée pour le moment, (et autres règles, etc.) ".. car il s'agit d'une règle métier (complexe mais non atypique), et doit donc être gérée dans le domaine d'application plutôt que de pousser la logique métier dans la couche db / persistance.
Cependant, il me semble que pour vérifier efficacement ces conditions, il va souvent être préférable de traiter avec une requête db bien conçue, plutôt que de charger toutes les données dans le domaine d'application ...
Sans optimisation prématurée, quelle est l'approche recommandée ou certains articles de l'oncle Bob traitant de cette question? Ou dirait-il "valider dans le domaine jusqu'à ce que cela devienne un problème" ??
J'ai vraiment du mal à trouver de bons exemples / échantillons pour autre chose que les cas d'utilisation les plus élémentaires.
Mise à jour:
Salut à tous, merci pour les réponses. J'aurais dû être plus clair, j'écris (principalement des applications Web) depuis longtemps, et j'ai certainement déjà expérimenté et d'accord avec tous les sujets que vous décrivez collectivement (validez par backend, ne faites pas confiance aux données client, d'une manière générale ne poursuivez l'efficacité brute que lorsque cela est nécessaire, mais reconnaissez les forces des outils db lorsqu'ils sont disponibles, etc., etc.) et avez suivi le cycle de vie d'apprentissage des développeurs de "tout jeter ensemble" pour "construire un contrôleur de graisse géant avec des applications à N niveaux". , et maintenant vraiment aimer et étudier le style de responsabilité propre / unique, etc., essentiellement à la suite de quelques projets récemment évolués en règles commerciales assez maladroites et largement distribuées à mesure que les projets évoluaient et que de nouvelles exigences des clients se faisaient jour.
En particulier, j'examine l'architecture de style propre dans le contexte de la création d'API REST pour les fonctionnalités orientées client et d'utilisation interne, où de nombreuses règles métier peuvent être beaucoup plus complexes que pratiquement tous les exemples que vous voyez sur le net (même par les gars de l'architecture Clean / Hex eux-mêmes).
Donc, je suppose que je demandais vraiment (et je n'ai pas dit clairement) comment Clean et une API REST s'assembleraient, où la plupart des choses MVC que vous voyez ces jours-ci ont des validateurs de demandes entrantes (par exemple la bibliothèque FluentValidation dans .NET), mais où beaucoup de mes règles de "validation" ne sont pas tellement "est-ce une chaîne de moins de 50 caractères" mais plus "cet utilisateur appelant cet utilisateur / cet interacteur peut-il effectuer cette opération sur cette collection de données étant donné qu'un objet lié est actuellement verrouillé par l'équipe X jusqu'à plus tard dans le mois etc etc "... ce genre de validations profondément impliquées où BEAUCOUP d'objets de domaine métier et de règles de domaine sont applicables.
Dois-je transformer ces règles en un type spécifique de type d'objet Validator pour accompagner chaque utilisateur-interaction (inspiré par le projet FluentValidator mais avec plus de logique métier et d'accès aux données), dois-je traiter la validation un peu comme une passerelle, dois-je mettre ces validations DANS une passerelle (ce qui je pense est faux), etc etc.
Pour référence, je pars de plusieurs articles comme celui-ci , mais Mattia ne parle pas beaucoup de validation.
Mais je suppose que la réponse courte à ma question ressemble beaucoup à la réponse que j'ai acceptée: "Ce n'est jamais facile, et cela dépend".