Go meetup #18

**Hébergé par Pure Storage**

Veuillez noter qu'au bureau de Pure Storage, tous les participants à la rencontre devront signer un NDA générique utilisé pour tous les visiteurs du bureau afin de pouvoir assister à la rencontre.
Les portes sont ouvertes à partir de 17h30, les conférences débuteront à 18h00 et nous aurons 3 conférences.

**1\. Vilibald Wanča \(Pure Storage\)\, Introduction à l'architecture basée sur les cellules**

**2\. Miłosz Smółka\, Tuer l'héritage et autres histoires du CQRS**
Connaissez-vous le sentiment lorsque votre projet reste bloqué et que vous ne pouvez pas avancer ? Vous voyez plusieurs issues, mais toutes semblent tout aussi mauvaises. Vous commencez à vous demander si le projet est voué à l’échec ou s’il vous manque simplement des connaissances particulières. C’est ce que j’ai le plus ressenti en essayant de sortir des systèmes existants, mais c’est courant dans de nombreux projets.
Au fil du temps, j’ai appris que changer votre modèle mental peut révéler une solution que vous n’aviez pas vue auparavant. En repensant à certains de mes projets, j'ai réalisé que l'un des modèles qui m'a aidé à penser différemment était le CQRS. Peu importe si vous avez déjà utilisé le CQRS, car je n'ai pas l'intention de vous ennuyer avec des définitions abstraites. On a beaucoup parlé de la théorie du CQRS. Au lieu de cela, je veux montrer comment je l'ai utilisé dans la pratique. Je partagerai trois histoires réelles de différentes entreprises et projets où j'ai réussi à avancer et à mieux appréhender le CQRS. L’une d’elles était la plus difficile : supprimer l’ancienne base de code.

**Bio :** Miłosz Smółka écrit sur Go, les logiciels d'entreprise modernes et des sujets connexes sur [https://troisdots.tech](https://troisdots.tech/). Il aime partager ce qu'il a appris en travaillant dans des startups et en créant des produits dans différents domaines.

**3\. Robert Laszczak\, Repenser la conception pilotée par domaine en Go : des mythes à la complexité réduite des projets**
Diviser les problèmes en problèmes plus petits peut être une bonne stratégie pour résoudre des problèmes complexes. Mais parfois, au lieu d’accélérer le développement d’un projet, c’est l’inverse qui se produit. Au final, développer la fonctionnalité la plus simple nécessite le travail héroïque de 10 équipes sur une douzaine de microservices sur six mois. Cela vous semble familier ?
« Diviser pour régner » n’est pas la seule stratégie que nous pouvons mettre en œuvre dans des projets complexes. L'une des approches les plus établies permettant de simplifier la mise en œuvre de fonctionnalités avec une logique de domaine complexe est la conception pilotée par domaine (DDD).
J'ai trouvé DDD très utile dans plusieurs projets avec des domaines complexes sur lesquels je pouvais travailler. D’un autre côté, je sais que les gens croient à de nombreux mythes sur le DDD utilisé au Go. La plupart d'entre eux proviennent de l'utilisation de DDD dans des projets qui ne nécessitent pas une approche aussi sophistiquée ou de projets mis en œuvre par des personnes qui n'ont pas compris les principes de DDD.
Au cours de cet exposé, je démystifierai DDD et vous donnerai un exemple concret de la manière dont l'autonomisation de DDD a contribué à les simplifier et à augmenter la vitesse de développement.
Si vous ne travaillez pas actuellement sur un projet avec une logique de domaine complexe, cette présentation peut néanmoins vous être utile si vous souhaitez travailler sur des projets plus ambitieux à l'avenir. Je vais également vous donner quelques conseils sur les parties de DDD à partir desquelles vous devriez commencer et quelles techniques fonctionnent bien avec DDD.

**Bio :** Je blogue sur threedots.tech. Auteur de "Go With The Domain" et de [Watermill.io](https://watermill.io/).
Mon parcours en programmation s'étend sur 16 ans, au cours desquels j'ai parcouru divers domaines, notamment l'infrastructure, les plateformes financières mondiales et la sécurité. Il y a quelques années, j'ai enfin trouvé une langue que j'adorais : le go.