Making the Domain Tangible: Implicit Object Lookup for Source Code Readability

  • Patrick Rein
  • Marcel Taeumel
  • Robert Hirschfeld
Part of the Understanding Innovation book series (UNDINNO)


Programmers collaborate continuously with domain experts to explore the problem space and to shape a solution that fits the users’ needs. In doing so, all parties develop a shared vocabulary, which is above all a list of named concepts and their relationships to each other. Nowadays, many programmers favor object-oriented programming because it allows them to directly represent real-world concepts and interactions from the vocabulary as code. However, when existing domain data is not yet represented as objects, it becomes a challenge to initially bring existing domain data into object-oriented systems and to keep the source code readable. While source code might be comprehensible to programmers, domain experts can struggle, given their non-programming background. We present a new approach to provide a mapping of existing data sources into the object-oriented programming environment. We support keeping the code of the domain model compact and readable while adding implicit means to access external information as internal domain objects. This should encourage programmers to explore different ways to build the software system quickly. Eventually, our approach fosters communication with the domain experts, especially at the beginning of a project. When the details in the problem space are not yet clear, the source code provides a valuable, tangible communication artifact.


  1. Beck, K. (2000). Extreme programming explained: Embrace change. Reading: Addison-Wesley Professional.Google Scholar
  2. Buschmann, F., Henney, K., & Schmidt, D. (2007). Pattern-oriented software architecture, on patterns and pattern languages (Vol. 4). Chichester: Wiley.Google Scholar
  3. Euzenat, J., & Shvaiko, P. (2013). Ontology matching (Vol. 2). Berlin: Springer.CrossRefGoogle Scholar
  4. Evans, E. (2004). Domain-driven design. Boston: Addison-Wesley Professional.Google Scholar
  5. Fowler, M. (1999). Refactoring – Improving the design of existing code (Addison Wesley Object Technology Series). Reading: Addison-Wesley.Google Scholar
  6. Goldberg, A., & Robson, D. (1983). Smalltalk-80: The language and its implementation. Reading: Addison-Wesley Longman.Google Scholar
  7. Kay, A. C. (1996). The early history of smalltalk. In History of programming languages—II (pp. 511–598). New York: ACM.Google Scholar
  8. Meyer, B. (1997). Object-oriented software construction (2nd ed.). Upper Saddle River: Prentice Hall International.Google Scholar
  9. Papakonstantinou, Y., Garcia-Molina, H., & Widom, J. (1995). Object exchange across heterogeneous information sources. In Proceedings of the 11th International Conference on Data Engineering (pp. 251–260).Google Scholar
  10. Russel, S., & Norvig, P. (2003). Artificial intelligence: A modern approach. Boston: Pearson Education.Google Scholar
  11. Sandberg, D. W. (1988). Smalltalk and exploratory programming. ACM SIGPLAN Notices, 23(10), 85–92.CrossRefGoogle Scholar
  12. Ungar, D., Lieberman, H., & Fry, C. (1997). Debugging and the experience of immediacy. Communications of the ACM, 40, 38–43.CrossRefGoogle Scholar
  13. Wegner, P. (1987). Dimensions of object-based language design. In Proceedings of the Conference on Object-Oriented Programming Systems, Languages, and Applications (pp. 168–182). New York: ACM.Google Scholar
  14. Wegner, P. (1990). Concepts and paradigms of object-oriented programming (Vol. 1, No. 1, pp. 7–87). SIGPLAN OOPS Messenger.Google Scholar

Copyright information

© Springer International Publishing AG 2018

Authors and Affiliations

  • Patrick Rein
    • 1
  • Marcel Taeumel
    • 1
  • Robert Hirschfeld
    • 1
  1. 1.Software Architecture Group, Hasso Plattner InstituteUniversity of PotsdamPotsdamGermany

Personalised recommendations