« Patterns de Core Domain » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
|||
| (2 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 86 : | Ligne 87 : | ||
==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/> | ||
