투명도(1/1) - 주최자 계산

Etre transparent sur son travail ça n'est pas toujours simple et possible. 에비덴테스 드 기밀 유지에 대한 질문을 따르십시오.

On peut néanmoins en extraire des morceaux à partager.

J'ai eu à travailler sur un projet dans le domaine de l'agriculture, où le besoin était de fournir une interface pour saisir des données et afficher des calculs.

Le soucis que l'on a rencontré, c'est que les calculs il y en avait beaucoup, pas très simple et pour ceux qui n'y connaissent rien, assez compliqué à vérifier.

En effet comment savoir que tel résultat est juste si on a aucune idée de ce qu'on doit obtenir ? Surtout où les données sont des pourcentages, des nombres à virgules...

Demander de l'aide à l'expert du domaine

Ce que j'ai fais en premier Lieu, c'est demander à "l'expert"du domaine chez le client de nous remplir un fichier yaml sous un format précis.

Je lui demandais de me donner le nom du calccul, les valeurs en entrées et le résultat attutu.

calculs:
  calcul_A:
    given:
      param_1: 2.2
      param_2: 0.01
      param_3: 32
    expected: 8

Ainsi on a pu tester automatiquement énormément de calculus, et s'il nous soumettait un nouveau fichier yaml, on a pouvait le valider rapidement.

계산법 구현

Je me suis demandé comment Organizer le code pour tous ses calculus.

Mon architecture est basée sur le modèle hexagonale, et sur une philosophie DDD. J'ai donc un Dossier AgricultureContext (j'invente un nom pour l'article), et je ne voulais pas que les calculus fasent partie de ce contexte.

뿌르콰이? et bien les calculus, c'est toute une connaissance à part entière à gérer, qui peut être indépendante du reste du projet. Je me suis dis, peut-être que je devrai penser comme si les calculus venaient d'aileurs, comme une API externe.

Du coup j'ai pensé, pourquoi ne pas faire un autre contexte dédié aux calcculs. Au final tout ce qu'on veut c'est que pour des données en entrées, on souhaite obtenir un resultat.

Dans ce contexte, on retrouvera des éléments commun en terme de nommage (en DDD on parle tous le meme language, mais selon les contextes on en fait pas la meme selected), mais le but de ce contexte, c'est d'effectuer des 미적분과 지식을 논평 레 페어.

Je suis un fervent défenseur de "독특한 책임". Un class ne doit fair qu'une seule는 et bien을 선택했습니다. On peut étendre ce concept à un niveau plus général, c'est pourquoi j'ai voulu sortir les calculs du contexte Agriculture.

CalculContext에 영향을 받지 않는 계산에 대한 코드 및 계산에 대한 Ainsi. On pourrait meme un jour faire un autre projet séparé, reprenant le code du CalculContext, et pourquoi pas à la place de partager une interface dans un monoprojet, de passer par une API.

En tout cas c'est la voie que j'ai choisi. Avec le recul, est-ce que j'aurai pu mettre tous les calculs dans le meme contexte ? J'y ai pensé, mais à Faire ça, je sais que j'aurai eu un code très couplé avec le domaine et moins simple à tester.

Donc pour Faire le Lien entre les deux contextes, j'autorise un service à être appelé dans le contexte 농업. "d'anti-corruption layer"라는 개념을 따르십시오. C'est à dire transforme le model d'un domaine vers un autre. Par exemple traduire une classe vers une autre, du json vers une classe, ou une classe vers du xml etc. Le but étant de ne pas manipuler les données d'un autre domaine sans l'avoir transformé pour son propre domaine auparavant.

Si je n'avais pas fais ça, je me serai retrouvé à manipuler des classes d'un autre domaine (un autre namespace), ce qui viendrait à coupler notre code très fortement et casser les barrières de nos contextes. Ne faites pas cela.

관련된 계산법 en eux mêmes, j'ai choisi de créer une classe par calcul, avec en paramètres un tableau de données, avec validation des noms et du type Attendu.

Et voilà on arrival à la fin de cette petite transparence de code.

J'essaierai d'en écrire d'autre, j'ai plein de sujet en tête.