Clojurians Log v2

[Off topic] Extrait des tests de ma propagation des diff - les Clojuriens bordelais comprendront.

(let [state {:items [nil nil nil {:name "Pain au chocolat"} nil]}
          new-state {:items [nil nil nil {:name "Chocolatine"} nil]}
          diff (h/map-update :items (h/vec-update 3 (h/map-assoc :name "Chocolatine")))
          subscriber-tree (-> empty-subscriber-tree
                              (subscribe-on-path [] 1)
                              (subscribe-on-path [:items] 2)
                              (subscribe-on-path [:items 3] 3)
                              (subscribe-on-path [:items 3 :name] 4))]
      (is (= (state-diff->subscribers state diff subscriber-tree)
             [[1 {:state state
                  :new-state new-state
                  :diff diff}]
              [2 {:state (-> state :items)
                  :new-state (-> new-state :items)
                  :diff (h/vec-update 3 (h/map-assoc :name "Chocolatine"))}]
              [3 {:state (-> state :items (get 3))
                  :new-state (-> new-state :items (get 3))
                  :diff (h/map-assoc :name "Chocolatine")}]
              [4 {:state (-> state :items (get 3) :name)
                  :new-state "Chocolatine"
                  :diff (h/value "Chocolatine")}]])))

Pour revenir sur le concept de CRUD, le problème est que le modèle est assez limité (en gros l’utilisateur édite des record/lignes de la base de données) et ça ne prend pas en compte toute la subtilité des interactions avec le logiciel car derrière l’update se cachent souvent tout un tas de règles métiers planquées. Une approche beaucoup plus fine et puissante avait été proposé avec le framework Naked Object, cf le bouquin https://b-ok.cc/book/1010067/44fb2f et la thèse de Pawson là-dessus : http://isis.apache.org/docs/ug/fun/_attachments/core-concepts/Pawson-Naked-Objects-thesis.pdf En gros la UI et tout le reste dérive complètement du modèle objet du domaine. J’expérimente depuis quelques mois sur l’utilisation des concepts DDD en Clojure, donc data-driven, pour décrire le domaine et dériver la logique applicative (endpoint REST, UI, http://etc.et d’infrastructure (persistance, messaging, sécurité) depuis ces data structure qui décrive le domaine. Pour ceux que ça intéresse on peut se faire une session de brainstorm là-dessus. L’aspect dynamique et data-driven de Clojure peut complètement changer la donne sur ce genre d’approche. Le point clé est d’avoir un méta-modèle de description du domaine suffisamment expressif et puissant pour dériver le reste du code avec des hooks placés aux bons endroits pour ce qui resterait spécifique.

@jeremie le lien de la thèse est cassé

> Le point clé est d’avoir un méta-modèle de description du domaine suffisamment expressif et puissant pour dériver le reste du code avec des hooks placés aux bons endroits pour ce qui resterait spécifique. Bon, pour ça tu sais déjà ce que je propose 😉 https://vvvvalvalval.github.io/posts/2018-07-23-datascript-as-a-lingua-franca-for-domain-modeling.html

Tu as peut-être entendu parler du Hodur, qui dérive de cette approche ? https://github.com/hodur-org

(Je ne recommande pas particulièrement Hodur. Ils traitent la base DataScript sous-jacente comme un détail d'implémentation, alors que je pense qu'il est généralement plus sain d'en faire l'API du modèle, pour ne pas tomber dans les mêmes travers que d'autres frameworks. Mais bon, ça pourrait t'intéresser).