In software, certain concepts are at the topmost layer. For instance, Separate things that change from things that stays the same or Separate things that change at different rates. These principles are at the top and there are architectures like Layered Architecture and MVC that are at the lower layers of the abstraction layer. Similarly, concepts such as Program to an Interface is at the top and principles such as polymorphism, Open Closed Principle etc are below that level.
Domain Driven Design book is a great book. The problem is that it stays at the topmost layer of the abstraction layer for too long. For instance the chapter about domain model, shows an example at the very end of the chapter. A good explanation varies the abstraction levels within the same paragraph or even within a sentence. If the audience is familiar with the concepts, then it is ok to stay at a high level of abstraction. The book does have code samples in Java that makes the concept clear. Nothing is more concrete than showing code examples to illustrate the high level concepts.
The Ladder of Abstraction is a useful tool for writing. It can be used to organize the software development principles. We look for characteristics that are common among objects/concepts to go higher up the abstraction ladder. As we make the high level concepts concrete, we are adding context to the abstract concepts. By providing a context, the reader has a chance to see how it impacts their live. Explanation that shows a scenario that the reader has encountered in the past can make the abstract concept clear. Writers can use simile and analogy that fails in the ladder of abstraction to make things clear.
How does the Ladder of Abstraction relate to the Govin's Knowledge Vee diagrams? It would be interesting to compare them and see if we could get more insights into the way we perceive things in the real world.