Mantener un modelo al día

The usual explanation is discipline, and it is wrong. The same engineers who let a model drift for two years keep their test suite green every day, and the difference is not how much they care - it is that a failing test stops the pipeline and a wrong diagram does not stop anything.

Code is surrounded by machinery that forces attention onto it at the moment it changes: a compiler, a test run, a reviewer who has to approve. A model in a wiki has none of that. Nothing in the path from ticket to production ever requires anybody to open the page, so nothing ever surfaces the disagreement. The model does not get worse - the system moves, and the model stays exactly where it was.

Every arrangement that works has the same shape: the model is placed where an existing step will run into it.

Put the view in the repository. A diagram committed as Mermaid beside the code appears in the diff when its file is touched and gets read by whoever reviews the change. It is the only mechanism on this list that costs nothing to sustain, because the review was already happening.

Reference views from decision records. A short architecture decision record that links the view showing the structure it decided means the view gets opened every time somebody asks why the structure is that way - which is precisely when its being wrong would matter.

Make the model the source of a thing people need. If the deployment view generates the diagram in the runbook, or the domain model generates the glossary the support team searches, then somebody notices within days rather than quarters.

The other half of the answer is that most models are too big to keep, and no process fixes that. If maintaining the model would take a day a month and the team has an hour, the model will go stale regardless of how the review is arranged - so the honest move is to cut it down to the hour.

That is the same test as scoping, applied later: whichever views cannot name a decision are the ones to drop, and dropping them is not a loss because they were not being read. What remains is small enough that its being wrong is noticed.

Then actually delete the rest. This is the step people will not take, and it is the one with the clearest arithmetic. A missing diagram costs a reader ten minutes of asking somebody; a confidently wrong diagram costs them a day and, if they are unlucky, a decision made on it. Documentation you will not maintain is not neutral, it is a trap with your team's logo on it.