p { margin-bottom : 0,1in ; line-height : 120% ; }
Selon ma méthode, c'est probablement la chose la plus importante dans l'architecture et la conception de logiciels.
- Quand vous allez écrire une solution logicielle, vous devez distinguer deux domaines : le domaine du problème et le domaine de la solution
- Les clients, le monde, l'entreprise, via l'équipe produit façonnent ou construisent le domaine du problème, tandis que les bons architectes logiciels, sont responsables de la conception du domaine de la solution, qui comprend les constructions, les concepts et la technologie par lesquels la solution sera mise en œuvre
- Le domaine du problème et le domaine de la solution sont décrits à l'aide de modèles et de concepts.
- Les concepts, et surtout les différents éléments du modèle's (entités, relations, comportements, processus) est ce qui serait matérialisé en éléments logiciels.
- Une incohérence dans la définition des concepts conduira soit à un modèle cassé - une faille logique qui à un moment ou à un autre sera soit :
- Cause un bogue (généralement quelques-uns) - soit un petit bogue, comme un petit morceau de fonctionnalité qui ne'fonctionne pas bien, soit un bogue sérieux
- Cause la solution d'être une non-solution - c'est-à-dire qu'elle ne'correspond pas au domaine du problème
Souvent vous'verrez des architectes ou des développeurs expérimentés se disputer sur le nom d'un composant logiciel. Cela peut sembler absurde pour un spectateur, mais c'est loin d'être le cas, car pendant qu'ils se disputent sur le nom, la chose plus profonde qui se passe dans leur tête est le raffinement des concepts liés à cet artefact logiciel et aux autres éléments de modèle qui lui sont associés. Il s'agit souvent de définir clairement la responsabilité des différentes entités et processus, etc. du modèle, sans trop de zones grises et certainement sans définitions contradictoires ni pièces manquantes. - En d'autres termes - ils travaillent sur l'intégrité conceptuelle de la conception.