J'ai écrit mes premières lignes de code à l'âge de 11 ans sur un ZX81. J'ai développé des écrans Videotex :-o Je suis artisan développeur depuis 30 ans déjà, j'ai aussi été architecte logiciel, chef de projet, responsable d'équipe , j'ai travaillé pour diverses ESN et éditeurs logiciels, dont Varian Medical Systems pendant 10 ans, Primobox plus récemment. Actuellement Senior Dev chez Sunday. C# + JS depuis le début, j'ai récemment plongé dans Kotlin avec délectation. Je pense que bien développer c'est: 70% de discussion, 20% de tests, 10% de code.
Description de votre session
DDD, mais qu'est ce donc encore que ce truc? Une méthodo? Une norme? Un process? Un N-ième truc agile?
Rien de tout ca!
20 ans ce sont écoulés depuis la première publication du "manifeste" DDD (le Blue Book) par Eric Evans. Et peu encore connaissent, ou pratiquent le Domain Driven Design.
C'est du design, mais pas que.
Ce sont des patterns pour coder, mais pas que.
C'est de l'organisation d'équipes, mais pas que.
Ca parle aussi d'architecture hexagonale, de CQRS, d' Event Sourcing, mais pas que.
C'est du bon sens, ca c'est certain.
Ca se mixe bien avec le TDD, l'agilité, le BDD et plein d'autres choses.
Informations diverses
Sujet:
[X] craft/qualité
[X] coder/tester/deployer
[ ] éthique
[X] équipes / RH
[X] Product Owners / PM
[ ] REX
[ ] alien
Niveau de difficulté :
[X] débutant
[x] confirmé
[ ] expert
Durée :
[X] 30 mn
[ ] 45 mn
[ ] 90 mn (atelier)
Format : slides et discussion
Disponibilités :
[x] jeudi 1er Juin
[x] vendredi 2 Juin
Règles de courtoisie
[ x] J'ai lu le code de conduite, j'en comprends la teneur et je m'engage à le respecter
le DDD à quoi ca sert?
Guillaume SAINT ETIENNE
J'ai écrit mes premières lignes de code à l'âge de 11 ans sur un ZX81. J'ai développé des écrans Videotex :-o Je suis artisan développeur depuis 30 ans déjà, j'ai aussi été architecte logiciel, chef de projet, responsable d'équipe , j'ai travaillé pour diverses ESN et éditeurs logiciels, dont Varian Medical Systems pendant 10 ans, Primobox plus récemment. Actuellement Senior Dev chez Sunday. C# + JS depuis le début, j'ai récemment plongé dans Kotlin avec délectation. Je pense que bien développer c'est: 70% de discussion, 20% de tests, 10% de code.
Description de votre session
DDD, mais qu'est ce donc encore que ce truc? Une méthodo? Une norme? Un process? Un N-ième truc agile? Rien de tout ca! 20 ans ce sont écoulés depuis la première publication du "manifeste" DDD (le Blue Book) par Eric Evans. Et peu encore connaissent, ou pratiquent le Domain Driven Design. C'est du design, mais pas que. Ce sont des patterns pour coder, mais pas que. C'est de l'organisation d'équipes, mais pas que. Ca parle aussi d'architecture hexagonale, de CQRS, d' Event Sourcing, mais pas que. C'est du bon sens, ca c'est certain. Ca se mixe bien avec le TDD, l'agilité, le BDD et plein d'autres choses.
Informations diverses
Règles de courtoisie