Designs grow structure for reasons that are not requirements. Someone read about a technique, someone expects a load that is not in the brief, someone wants the design to still be right if the product changes direction. Each added component is real and permanent: it must be deployed, monitored, secured, upgraded and understood by everyone who joins later, and it adds a way for the system to fail. So the test for a piece of structure is not whether it might be useful, it is whether removing it makes some written scenario fail. Run that test on every box and every arrow. If a component's removal breaks a scenario, it has earned its place, and you can say which scenario it serves. If nothing breaks, the component is being kept for a requirement nobody wrote down, and the honest move is either to write that requirement and rank it, or to delete the component. This is not an argument for building carelessly. A design that meets every scenario with less structure is strictly better than one that meets them with more, because it can be changed faster when the scenarios change. You can now defend or delete each part of a design by naming the scenario it exists for, and recognise structure that is being carried for an unwritten requirement.
Over-engineering is the practice of introducing complexity, abstraction, or generality into a solution beyond what is required to solve the actual problem, in contrast to engineering, which is define…