Bonne introduction pour le DDD. J'ai un bon background en modélisation. Et j'ai pu vraiment me rendre compte que l'important n'est pas d'avoir un seul modèle d'où tout découle, mais dans les transformations entre modèles et leur différente transformation. L'exemple typique est son modèle bien propre, que l'on veut sauver dans une base de donnée. Il y a une infinité de manière de faire. On peut toujours bricoler une sérialisation ad-hoc, mais si on fait une sorte d'ORM automatique, il faut faire un tas de choix qui peuvent avoir de gros impact en performance (primary key, index,...), le pire étant les différences de sémantiques subtiles (gestion des nul ou des string vide, la taille d'entier, cycle de vie, etc...)
Donc, je suis persuadé qu'il faut un modèle "propre" pour faire ses services business, mais un autre modèle dérivé d'un modèle dédié au base de donné. Et le code important devient le code de transformation d'un modèle à l'autre. C'est d'autant plus intéressant si on récupère une base existante.
Donc, je n'aime pas trop le modèle en couche. Soit les couches masquent trop de complexité, et écrire les étages supérieurs devient un calvaire, soit elle rejette la complexité vers les couches hautes, mais sans fournir toutes les informations pour pouvoir réagir correctement. La mode est au micro-service qui sont des découpes verticales. Cela a le bon gout de coller avec le principe de Bounded Context du DDD.
En tout cas, merci pour l'info concernant cet outil.
[^] # Re: Domain Driven "Design"
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Conception pilotée par le domaine ou Domain-driven design (DDD). Évalué à 4.
Bonne introduction pour le DDD. J'ai un bon background en modélisation. Et j'ai pu vraiment me rendre compte que l'important n'est pas d'avoir un seul modèle d'où tout découle, mais dans les transformations entre modèles et leur différente transformation. L'exemple typique est son modèle bien propre, que l'on veut sauver dans une base de donnée. Il y a une infinité de manière de faire. On peut toujours bricoler une sérialisation ad-hoc, mais si on fait une sorte d'ORM automatique, il faut faire un tas de choix qui peuvent avoir de gros impact en performance (primary key, index,...), le pire étant les différences de sémantiques subtiles (gestion des nul ou des string vide, la taille d'entier, cycle de vie, etc...)
Donc, je suis persuadé qu'il faut un modèle "propre" pour faire ses services business, mais un autre modèle dérivé d'un modèle dédié au base de donné. Et le code important devient le code de transformation d'un modèle à l'autre. C'est d'autant plus intéressant si on récupère une base existante.
Donc, je n'aime pas trop le modèle en couche. Soit les couches masquent trop de complexité, et écrire les étages supérieurs devient un calvaire, soit elle rejette la complexité vers les couches hautes, mais sans fournir toutes les informations pour pouvoir réagir correctement. La mode est au micro-service qui sont des découpes verticales. Cela a le bon gout de coller avec le principe de Bounded Context du DDD.
En tout cas, merci pour l'info concernant cet outil.
"La première sécurité est la liberté"