2018-06-26
How Different it is when we focus on the business-side?
Meetup organisé par #DDDPARIS
Grégory Weinbach @gweinbach
Du champ de betteraves au champ texte
1er poste de coût : l'usine
2e poste de coût : le transport.
L'usine est déjà bien analysée, comment réduire les coûts du transport ?
Betteraviers = des experts de père en fils. Planifier, Organiser, Piloter. Outillés avec SAP.
The Green Data = datascience, stats. Intervention sur la partie Planifier.
Des dizaines de milliers de rotations de camion à planifier, avec une carte papier, un simple fichier excel et une abaque de distances.
Green Data passe après deux prestataires qui ont déjà essayé d'informatiser le planning sans succès. Pourtant ça n'a pas l'air compliqué.
Et pourtant, le premier essai d'application est raté, car les bonnes conversations n'avaient pas eu lieu. Par exemple le poste de grue planifié != poste de grue executé. Après beaucoup d'échanges, le deuxième essai est réussi.
Les processus humains qui n'ont jamais été informatisés sont complexes et ont beaucoup de valeur. C'est un exemple où l'étude du domaine, rendre explicite l'implicite, et distiller le domaine est difficile et important.
Thomas Jaskula @tjaskula
Why Vietnam war ever happened?
Rappels sur les raisons de la guerre du Vietnam.
Miscommunication.
Robert McNamara.
Mindset of americans ≠ mindset of Vietnameses.
DDD enforces strong communication.
- Language (UL)
- Explicitness (BC, Context Maps, etc.)
- Involves different actors (Devs, Business people, etc.)
- Force to think outside the box (changes mindset)
Comment est-ce qu'ils ont découvert DDD ?
Au départ Thomas parle du jargon DDD, qu'il vient de découvrir à son équipe (Bounded Context, Ubiquitous Language, etc.) Ça marche peu.
Le contexte : fossé entre dev et business analystes qui voulaient "prendre de la hauteur par rapport au métier", généraliser plutôt que prendre des exemples.
Aucun contact métier avec les devs, que les business analystes.
Ce qui a mieux marché : Thomas a cherché, trouvé, invité un expert métier (qui n'en était pas un officiellement) pour parler avec les devs, et a invité les business analystes. Les conversations qui ont eu lieu ont amorcé un dialogue, et une curiosité.
Pour Jérémie, en s'intéressant au métier et en faisant du simple Java, il n'a pas eu besoin de mettre en place un outil de BPM (Business Process Management).
Pour commencer DDD tout est question de language dans le contexte des gens qui vont l'utiliser. On a besoin de conversations, d'exemples concrets.
Intéressez-vous à l'espace du problème et pas à l'espace de la solution.
Cherchez les problèmes, et n'en créez pas trop.
Yves Reynhout @yreynhout
Exemple d'un produit (Clouso). Les commerciaux sont fiers de pouvoir proposer un produit qui s'adapte à tous les clients, avec des champs supplémentaires à la demande par exemple. L'architecte est fier de toutes les abstratctions qu'il crée. Mais un nouveau développeur met plus d'un mois à devenir productif. Et c'est une Big Ball of Mud.
Comment ils en sont arrivés là ?
Inertia (to resist change) is a model's enemy.
Ils ont commencé leur produit pour des petits musées.
Séparer les problèmes
Inertia is a role's enemy.
PO qui donne des requirements compliqués sous forme de texte. Ça a l'air compliqué, est-ce que tu es sur que c'est ce que tu veux ? Bien sûr, c'est ce que veut l'utilisateur. Pour sortir de ça, essai de visualiser. Ça donne un truc énorme. On commence à voir les contradictions. Demande au PO d'expliquer le diagramme au métier.
Could we invite our trainer (a former domain person) in our next specification meeting? Because if you have a hard time explaining to him, it will be even harder to explain our customers.
Yannick Grenzinger @ygrenzinger
On parle souvent de dette technique, il y a aussi la dette fonctionnelle : quand le métier finit par s'aligner sur une mauvaise application. Souvent les gens voient le legacy comme référence mais pas le métier.
On fait beaucoup de réunions avec des gens qui ont une vue parcéllaire du métier, sans les vrais utilisateurs. On n'arrive pas à prendre de décision.
Message à caractère informatif deux, La réunion de l'angoisse.
Si le legacy est difficile à changer, il devient le métier. Souvent c'est compliqué parce-que le métier a été perdu.
Ça a été une vrai bataille de se battre contre un code qui a finit par devenir le métier. Il faut résister contre l'inertie du legacy en place.
For Guerilla DDD you must:
- Learn to say no
- Find the hidden domain expert
- Make everything to talk to him
- Define clear domain by yourself if necessary (quand vous n'avez pas accès au métier et que quelque-chose ne fonctionne pas. Proposer la modélisation de métier le plus simple et aller voir si ça marche.)
- Hack the culture (plus important que de parler de Bounded Context ou d'Ubiquitous Language)
Mathias Verraes (organisateur de DDD Europe) @mathiasverraes.
The old solution is the new problem. This happens over and over, it will probably to the project you are working on now.
Coupling. If it’s coupled in the mind of the domain people, then it will probably also be coupled in the software.
Coupling very often leads to coordination problems. Coordination problems are more expensive.
We should challenge what the domain is doing, does it really have to be this way ?
Example of a core domain of warehouse management solution that was designed to be foolproof because the work was done by humans. On the new warehouse, the work is now done by robots, that don't make human mistakes. The foolproof domain is no longer relevant and causes problems, addressed with workarounds & coupling. The old solution has become a problem.
Mathias, Eric, Yves
Il n'y a pas toujours un seul expert du domaine, parfois il faut aller voir une personne pour un point précis, et une autre personne pour un autre point.
Don't waste the time of domain experts with tech details.
Good question to ask to the domain experts for Eric Evans: "Tell me a story about something that really worries you, that keeps you up at night."
Eric Evans: The best way to learn is in your team, from the members that are better than you at something. For a long time I made sure to join teams where I would learn the most, with other more senior designers who were better than me.
Eric: the technologies that you learn today will be obsolete in 10 years. Learn deep things.
Mathias Verraes: There’s a misconception among developers that learning technologies is your only value, but learning domains in-depth is another way of delivering value, absolutely. But the domain you are learning will be completely different in the next project. So learn to learn a domain. Learn how to learn a domain.
Mathias: 2 good heuristics to learn a domain are: follow the money and follow the risks.
Eric: Look for it everywhere. Reading books about the domain. Going into something where everything seems arbitrary, is a mess, that is quite a challenge. Look for the principle underneath, ask "Why" questions. Why do we do that ? Why is it important ? Not in an obnoxious way, but by being interested. You need someone that knows the domain enough to know why, that knows the principles behind the rules.
Many domains don’t seem interesting until you scratch the surface and get deeper into their hidden complexity.
Example of mistake I used to make:
- Eric: make the domain grow too much, a model for a whole lot.
- Yves: not listening carefully enough to nuances of experts, perhaps because I was infatuated by all the technologies I knew
- Eric: Start a refactoring, and discover that it involves something else. After a couple of weeks, we discover again that it involves something else. I wish I had stopped there, accept to lose two weeks and rolled back.
- Mathias: Letting a model become more and more generic week after week until it becomes a key value store over http.
Eric: What I like about Microservices in the Netflix sense: every service is independant with independant teams. They are using the bounded context in the physical sense. You might get the benefits if you have to scale, or if you have a complex domain and you want to partition the logic. If you have neither of these you might not get benefits, only the difficulties.
I used to say that all software is bound to become a big ball of mud, you can only delay that moment. Sometimes the context is good and politics is good, and it goes well for a while.
Les messages qui m'ont marqué ce soir :
- Au départ d'un projet ou d'une feature, on pense que tout est simple. Mais au fur et à mesure qu'on avance, on découvre une complexité et une richesse métier progressivement. Un modèle trop simple a quand même une valeur quand il déclenche les bonnes discussions (mistakes build progress).
- Pour présenter DDD à une équipe, créer le bon contexte, générer les bonnes conversations, impliquer les bons experts métier, expliciter l'implicite, commencer à distiller le domaine est plus efficace que de présenter les mots clés (Bounded Contexts, Ubiquitous Language,...)
- Learn how to learn a domain
- Expliciter l'implicite, à tous les niveaux (même entre les personnes, cf Core Protocols)
- Mathias Verraes, Yves Reynhout, et Eric Evans sont tous les trois des gens accessibles, qui parlent calmement et avec humilité.