Quelle part d'un système modéliser
La seule question qui tranche est celle de la décision que le modèle doit éclairer - et l'essentiel de ce que les gens modélisent n'en éclaire aucune.
6 min de lectureModelling practice1 sur 3
01The test: name the decision
Before drawing any view, finish this sentence: "This view exists so that [person] can decide [thing]." If you cannot fill in both blanks, do not draw it.
The test works because it is falsifiable, which is what every other piece of advice on this subject is not. "Model the important parts" cannot lose an argument; "this class diagram exists so the platform team can decide whether billing owns the tax calculation" either is true or is not, and the person named can be asked.
Applied honestly it removes most of what gets modelled. A diagram of the current system drawn because somebody should document it informs nothing. A view showing every service in the estate informs nothing, because no decision is about all of them at once. What survives is a small number of views, each aimed at an argument somebody is having.
02Three ways an unscoped model fails
It becomes a second implementation. Every class, every field, every call - a model at that fidelity is a copy of the codebase written in a notation, and the copy is always the one that is wrong. This is the failure that gives modelling its reputation, and it comes entirely from not asking what the model is for.
It becomes a picture of the org chart. Unscoped models drift towards showing every team's system at equal weight, because that is politically the easiest arrangement. The result is a diagram in which the two components that actually interact are the same size as twenty that do not, and nobody can find the question.
It becomes unmaintainable in the ordinary way. Not dramatically - simply by containing more detail than the team has appetite to update, so a few elements go stale, then a few more, and within two quarters the model is a thing people check against the code rather than trust.
Reach for it when
- A decision is genuinely open and two people disagree about it
- A change will cross several teams and somebody has to see the seams
- A future reader will need to know why a non-obvious structure exists
- A new joiner needs the shape of the domain, not the shape of the code
Reach for something else when
- Documenting a system that nobody is about to change
- Recording a decision already made and already obvious from the code
- Modelling because a template or a process asks for a diagram
- Any level of detail the team will not maintain after the project ends
03Working at the right size
One model, several small views. Scope is a property of the view rather than of the model - the model can hold everything anybody has entered, and each view shows the handful of elements one decision needs. That distinction is what ArchiMate's viewpoint mechanism is for, and it applies just as well to UML.
Model one level below the decision, not two. If the argument is about which service owns a responsibility, model the services and their dependencies. Do not model the classes inside them; that detail cannot change the answer, and it is the detail that will rot.
Delete views that have served their purpose. A view drawn for a migration that happened is finished, and keeping it means a future reader will find a confident diagram of an architecture that no longer exists. Deleting documentation feels wrong and is usually right.
In one line each
- 01Every view must name a person and a decision. If you cannot, do not draw it.
- 02A complete model of an unbuilt system is confident guessing, and it hardens the guesses.
- 03Model one level below the decision. Detail that cannot change the answer will rot.
- 04Scope belongs to the view, not the model - one model, many small views.
- 05Delete a view once its decision is made. A stale diagram is worse than none.
Next in this series: naming conventions, and then keeping a model current.
04Questions fréquentes
Quelle part d'un système faut-il modéliser ?
Celle qui éclaire une décision que quelqu'un va réellement prendre. Pour chaque vue que vous allez tracer, nommez la décision qu'elle soutient et la personne qui la prend ; si vous ne pouvez nommer les deux, la vue documente un système au lieu d'aider à le changer, et elle ne sera pas lue.
Faut-il modéliser tout le système avant de commencer ?
Non. Un modèle complet d'un système que personne n'a construit est un ensemble de suppositions tracées avec assurance, et son principal effet est de rendre ces suppositions plus difficiles à abandonner. Modélisez la partie où la décision est réellement ouverte, construisez, puis modélisez la suivante quand la décision suivante arrive.
Comment savoir qu'un modèle est trop détaillé ?
Quand une modification du code obligerait à modifier le modèle et que personne ne le fait. C'est le point où le modèle contient plus de détail que l'équipe ne peut entretenir, et au-delà chaque diagramme s'éloigne du système tout en continuant à faire autorité.
À lire aussi