How domain driven design makes software development concrete and abstract
1 People will remember names.
Think of landscapes in the physical world. The allure of names like “Yosemite” or “The Grand Canyon” turns them into destinations with emotional appeal. Just naming them “canyon 1” would be a dump.
Technology is no different. I once worked in a multi-language assembly of a plane. There was a brown switch board, which always caused problems. In French it was called platine choco. In other languages, it had the beautiful sounding name CX115, or something else I do not remember.
Naming is one of the most important aspect of software development. Naming transforms sterile abstractions into memorable entities.
2 Your memory is not a computer storage
But why are names so important? Our brains aren’t file cabinets or computer storage; they’re Velcro, with loops waiting for the right hooks. The stickiest ideas, which can attach, are rich in details and relevance.
For instance, “silly things people have done” is an abstraction, but “silly things your child has done” creates vivid imagery, attaching to your personal experiences.
Software design and software management help from this principle. Specific technical scenarios and user stories anchor better in the team’s mind than generalized ideas.
3 The Curse of Knowledge: Engineers and Abstraction
Engineers are notorious for crafting elaborate blueprints without addressing the practical problems staring them in the face. While abstraction is necessary to achieve extensible and “soft” products, it needs to be limited for the sake of delivery speed.
4 An abstract solution to deliver concreteness: Domain-Driven Design
A better solution to overcrowded designs full of abstraction exists.
Domain-Driven-Design (DDD) embraces concreteness. By tying software elements to real-world concepts within a specific domain, DDD creates shared language and context among stakeholders. If those elements share something, we can generate an abstraction.
This makes it easier to communicate, collaborate, and build. Imagine if every class, function, or service in a system mirrored something tangible from its business domain. Not only does this foster clarity, but it ensures that every abstraction has roots in something real.
Concreteness forges connections and ensures memory retention. And even software abstraction should have concrete names. Whether you’re naming a software feature, crafting a narrative, or solving a problem, remember: the stickiest ideas are specific.