Partie III. Transformationstratégique axée sur le domaine
Dans la partie II, on a vu comment la transformation axée sur le domaine peut être gérée à petite échelle (techniquement et tactiquement) et en termes d'organisation de l'équipe. Maintenant, dans cette troisième partie du livre, on va regarder la transformation axée sur le domaine dans un contexte plus large, c'est-à-dire la décomposition d'un système existant. Pour ça, on veut comprendre le domaine qui se cache derrière pour pouvoir ensuite le décomposer en fonction des sous-domaines trouvés.
En quelque sorte, on a le problème inverse de celui qu'on rencontre lorsqu'on construit un nouveau système sur un site vierge.
Si tu veux développer un nouveau logiciel sur un site vierge pour un domaine d'application pour lequel il n'existe encore aucun logiciel spécialisé, tu dois déterminer quelles étapes des processus métier des utilisateurs (avec du papier et un crayon, ou avec Word, Excel et des e-mails) sont vraiment pertinentes et méritent d'être conservées. À ce stade, vous rencontrerez généralement des étapes du processus qui peuvent déjà être grandement simplifiées, voire rendues superflues sans logiciel, mais encore plus grâce au développement d'un nouveau logiciel.
Développement logiciel dans le brownfield
Si un logiciel existant a déjà été utilisé et développé au fil des ans, vous êtes plus susceptible d'observer ce phénomène : les processus métier ont évolué au fil des ans pour une ou plusieurs des raisons suivantes ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access