Creating abstractions is a key part of software development. We use abstractions at every level, whether it’s defining class hierarchies, setting component boundaries, or breaking down business processes. But how can we understand if our abstractions are good enough? That's the main topic of the Gregor Hohpe talk Build Abstractions not Illusions.
Key points from the talk:
✏️ Abstractions are needed to hide implementation details and reduce cognitive load for teams
✏️ Abstraction is the foundation of any model, models help us make better architecture decisions
✏️ Abstractions provide a higher-level vocabulary that hides underlying complexity. Abstractions should not be a composition of other elements (e.g., EngineGearWheelsAssembly instead of "car")
✏️ If an abstraction hides essential details, it becomes an illusion. Illusions are dangerous because they mislead users about the real system structure or behavior
✏️ Too much detail means it’s a composition; too little detail makes it an illusion. The right level of abstraction is a "gold" balance between these two.
The video suggests a really good model to think about abstractions in a scale
composition - abstraction - illusion. A practical tip to check your abstractions is to ask: What details are essential? Can they affect the correctness of the model? If these details are missing, could that lead to misunderstandings about the system's properties?#architecture