This only has an impact when we want to change a system. Coincidentally, the majority of our work is changing a system through addition of new functionality or maintenance. I've thought about this problem for a long time. The conclusion I've come to is that it happens because the code doesn't look like the domain. Domain language is often missing in the code the engineers are working with so when new changes are requ…
However, we can still do much more than that. Take your example of searching textually for a class / method. First, when we search by text we assume that code has no structure. Would it not be a significant optimization to have a search that allows you to be search semantically through your system?
Now, the problem is that a system is interesting from many different perspectives. - For example, a security issue is most likely going to be crosscutting the domain. When we look for it, we would like to see a projection of the system specifically for our problem. - Or take communicating with the domain specialists. Most often, that communication happens on the whiteboard. However, what is manually drawn on the whiteboard represents what the writer thinks, not necessarily what the system is. To see the system, we should want the system to draw itself on the whiteboard. Any manual intervention in this process introduces an interpretation that hinders the communication. So, we can start with writing on the whiteboard when the system does not exist, but as soon as it does exist, we should have the system draw its representation. That can enhance communication manyfold.