Koľko zo systému modelovať
Jediná otázka, ktorá to rozhodne, je, aké rozhodnutie má model podoprieť - a väčšina toho, čo ľudia modelujú, nepodopiera nič.
6 min čítaniaModelling practice1 z 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.
04Časté otázky
Koľko zo systému mám modelovať?
Toľko, koľko podoprie rozhodnutie, ktoré niekto naozaj urobí. Pri každom pohľade, ktorý sa chystáte nakresliť, pomenujte rozhodnutie a človeka, ktorý ho robí; ak neviete pomenovať oboje, je to dokumentácia systému a nie nástroj na jeho zmenu, a nikto ju čítať nebude.
Mám namodelovať celý systém pred začiatkom?
Nie. Kompletný model systému, ktorý ešte nikto nepostavil, je sada dohadov nakreslených so sebavedomím a jeho hlavným účinkom je, že sa tých dohadov ťažšie vzdáte. Namodelujte tú časť, kde je rozhodnutie naozaj otvorené, stavajte, a ďalšiu časť namodelujte, keď príde ďalšie rozhodnutie.
Ako spoznám, že je model príliš podrobný?
Keď zmena v kóde vyžaduje zmenu v modeli a nikto ju neurobí. To je bod, v ktorom má model viac detailu, než tím dokáže udržiavať, a za ním sa každý diagram vzďaľuje od systému a zároveň naďalej vyzerá dôveryhodne.
Súvisiace články