« Patterns de Core Domain » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
|||
| (4 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
[[Category: Portail Product Owner]] | [[Category: Portail Product Owner]] | ||
[[Category: Rôle du Product Manager]] | [[Category: Rôle du Product Manager]] | ||
[[Category: DDD]] | |||
Auteur : Nick Tune<br/> | Auteur : Nick Tune<br/> | ||
Source : [https://medium.com/nick-tune-tech-strategy-blog/core-domain-patterns-941f89446af5 Core Domain Patterns]<br/> | Source : [https://medium.com/nick-tune-tech-strategy-blog/core-domain-patterns-941f89446af5 Core Domain Patterns]<br/> | ||
| Ligne 68 : | Ligne 69 : | ||
==Core cygne noir== | ==Core cygne noir== | ||
[[Fichier:Core Domain Patterns 07.jpg|800px|link=]]<br/> | |||
''Core Domains cygnes noirs''<br/> | |||
<br/> | <br/> | ||
Il arrive parfois que l'on ne s'y attende pas du tout et qu'un produit apparemment banalisé devienne un "core domain". L'histoire de Slack me revient en mémoire.<br/> | Il arrive parfois que l'on ne s'y attende pas du tout et qu'un produit apparemment banalisé devienne un "core domain". L'histoire de Slack me revient en mémoire.<br/> | ||
| Ligne 75 : | Ligne 77 : | ||
<br/> | <br/> | ||
L'IRC (‘’ discussion relayée par Internet’’) était déjà une norme de discussion bien établie qui remplissait une fonction. Le potentiel de différenciation semblait faible. Personne n'y a vu d'opportunité, pas même Slack, qui utilisait pourtant le produit.<br/> | L'IRC (‘’ discussion relayée par Internet’’) était déjà une norme de discussion bien établie qui remplissait une fonction. Le potentiel de différenciation semblait faible. Personne n'y a vu d'opportunité, pas même Slack, qui utilisait pourtant le produit.<br/> | ||
== Core sur lequel on parie beaucoup / Core disruptif== | == Core sur lequel on parie beaucoup / Core disruptif== | ||
[[Fichier:Core Domain Patterns 08.jpg|800px|link=]]<br/> | |||
''Core sur lequel on parie''<br/> | |||
<br/> | <br/> | ||
Pour de nombreuses initiatives, le niveau potentiel de différenciation commerciale est inconnu. Tant que le produit n'est pas livré et que les retours du marché n'ont pas été recueillis, personne n'est sûr de rien.<br/> | Pour de nombreuses initiatives, le niveau potentiel de différenciation commerciale est inconnu. Tant que le produit n'est pas livré et que les retours du marché n'ont pas été recueillis, personne n'est sûr de rien.<br/> | ||
<br/> | <br/> | ||
En raison du potentiel élevé de cette capacité, qui pourrait révolutionner un marché, il peut s'agir d'un pari ambitieux, car l'organisation doit y injecter des ressources importantes et en faire un objectif prioritaire, convaincue que le retour sur investissement peut être énorme.<br/> | En raison du potentiel élevé de cette capacité, qui pourrait révolutionner un marché, il peut s'agir d'un pari ambitieux, car l'organisation doit y injecter des ressources importantes et en faire un objectif prioritaire, convaincue que le retour sur investissement peut être énorme.<br/> | ||
==Core suspecté de support== | ==Core suspecté de support== | ||
[[Fichier:Core Domain Patterns 09.jpg|800px|link=]]<br/> | |||
''Core suspecté de support''<br/> | |||
<br/> | |||
Si un contexte délimité est super complexe alors qu'il ne fait que du support, il convient de se poser de sérieuses questions. Comment quelque chose de relativement peu différencié sur le plan commercial peut-il nécessiter des niveaux d'investissement aussi élevés pour gérer la complexité ?<br/> | Si un contexte délimité est super complexe alors qu'il ne fait que du support, il convient de se poser de sérieuses questions. Comment quelque chose de relativement peu différencié sur le plan commercial peut-il nécessiter des niveaux d'investissement aussi élevés pour gérer la complexité ?<br/> | ||
<br/> | <br/> | ||
Une raison tout à fait valable est que cette complexité accidentelle est trop élevée - peut-être qu'une migration est en cours d'un ancien système vers un nouveau. Un plan clair et un calendrier de réduction de la complexité doivent être mis en place afin de garantir que les efforts gaspillés puissent être réaffectés à des capacités ayant un potentiel de différenciation plus élevé.<br/> | Une raison tout à fait valable est que cette complexité accidentelle est trop élevée - peut-être qu'une migration est en cours d'un ancien système vers un nouveau. Un plan clair et un calendrier de réduction de la complexité doivent être mis en place afin de garantir que les efforts gaspillés puissent être réaffectés à des capacités ayant un potentiel de différenciation plus élevé.<br/> | ||
== Passer au niveau supérieur== | == Passer au niveau supérieur== | ||
Je trouve que l'évaluation des contextes délimités pour la différenciation et la complexité de l'entreprise est un point de départ très pratique et accessible. Pour les équipes qui comprennent mal comment leur architecture est liée au modèle d'entreprise, j'ai trouvé cette technique incroyablement utile pour permettre aux développeurs de raisonner davantage en fonction de la perspective de l'entreprise, et en particulier de son évolution dans le temps.<br/> | Je trouve que l'évaluation des contextes délimités pour la différenciation et la complexité de l'entreprise est un point de départ très pratique et accessible. Pour les équipes qui comprennent mal comment leur architecture est liée au modèle d'entreprise, j'ai trouvé cette technique incroyablement utile pour permettre aux développeurs de raisonner davantage en fonction de la perspective de l'entreprise, et en particulier de son évolution dans le temps.<br/> | ||
