Yes, DDD! It stands for documentation-driven design. The goal is to have the documentation capture the domain usage for the respective users. Typically, documentation is written for the end, development and administrative users. Therefore, if the respective users find the documentation meaningful in the absence of running code then it is likely that the corresponding design is good. Furthermore, once the documentation is 'accepted', it is very unlikely to change since the domain is also unlikely to change. In this way, the documentation neatly encapsulates all the domain volatility so that the top level design remains invariant even in the face of massive modifications of the implementation. In fact, the implementation can change 100% without any discernible change in the top level design. The only requirement is that the test suite conserves the top level design to prevent breaking changes.
I really like this idea!
DDD examines how usable the tool is. Shorter documentation which covers everything is to be preferred. It is age easier to debug documentation than the actual tool. Furthermore, by testing how effective the documentation is you can understand how usable they tool is. In fact, you can completely simulate the actual operation to see how effective the documentation is.