The word "domain" has more than one meaning in software development. It can mean, as it does in xCase, the collection of field types that specify more than just the basic field settings, including things such as default caption, allowed values, etc. That way when adding a field (column) to to entity, all that other metadata flows to the initial field definition. Another meaning for domain is the particular set or collection of knowledge that the software expresses or articulates. The Retail Inventory Management Domain is different from the Point Of Sale (POS) domain, which in term is different than the Logistic domain, and so forth. A domain in this latter sense is characterized by having boundaries, and by having great depth.
Generally speaking, looking at areas of activity that embody complexity, it takes a minimum of 10 years to master a domain. Within 2 or 3 years some proficiency will have been gained, but the internal map that guides in new situations takes longer than that to develop.
The great impedance mis-match in software development is between domain knowledge and software development ability. The old "waterfall" approach was to specify everything the software needed and have the knowledge flow down, through the system architect to the software engineer. It doesn't work. Putting aside workflow issues involved with the waterfall development paradigm, there is a critical mistake made in assuming that a domain can be fully articulated by a domain expert. Can a surgeon articulate that internal map that let's her deal with the unexpected? Can a baseball shortstop? Can a psychologist articulate that internal map that guides him when helping a unique individual (and we are all unique)? The fact is, that internal map is articulated only in context, in the context of use.
What this argues for, and what we have been doing for over 15 years now, is getting the professional software developer out of the way of the domain expert. In this model, the domain expert is given the tools to articulate the domain in context -- the context the software is being made to serve. The role of the professional software developer, in domain expert software development, is to provide the tools the domain expert needs to express the domain. The domain experts with whom we have worked extensively (in the fields of HR, Trash Management, Retail Inventory Management, Nuclear Facility Management) are among the best in the world. They are not professional programmers, but their software is professional software, and competes well with software written by large teams of programmers, at great expense.
Our use of metadata and frameworks makes all this possible. That plus custom improvements to our libraries based on their needs. And working with the developers of the tools we use to foster integration with our tools. No where has this been a better match than with our current (and future) choice of the Lianja development and deployment stack.