Follows the situation for discussions about MDApps, it should be done a discussion about the definition of model-driven application. Such the words, including model-driven enterprise application, model-driven information system and so on, are already used by us about a decade, it can be seen there are a few similar usage , but so far have not seen a complete and clear definition yet. A specialized definition is raised in . We suggest use model-driven application to denote two of meanings: one is a class of application systems (simply, applications; apps); other is the related ideas, the approach to the apps, the architecture, or the study. With the reference to certain habits, such as Information Systems, use the plural form for the latter.
MDApp as a system
According to the paper , “a model-driven application (MDApp for short) is a model-driven system,” in which its functions or behaviors are operated / based on, or in control of, some evolutionary applied model of the target things to the application. That definition is based on more general concepts, the model-driven systems (MDS) and model-driven mechanism (MDM), which present the constructive principles of MDApps. There are three keywords to understanding this concept.
First, the term applied model is defined in MDM. It means the model is served as a part of the app system, and the target (that is, what being modeled by the model, see here) of the model is the thing handled by the user via the app; in other words, it is not the model of the function or behavior of the system but controls / governs them.
Second, the term target here is in a dual use but aimed at the same goal, as mentioned above, one is for the applied model, one is for the app system, and the target things of the system are what being modeled by the applied model. For example, an app for warehouse, the target things may including cargo space, goods, inventory, delivery order, delivery process, and so on, then, the applied models will be cargo space model, goods model, inventory model, delivery order model, delivery process model, and so forth .
Third, the applied mode is evolutionary implies that the system is running / operating on it, and the user of the app be enabled to add / modify / remove the applied model when the system is in operation, namely, at runtime. It means that the system is able to adapt to the changes of its target thing through updating the applied model by user. For example, if you want the system to handle some orders, they must be modeled in the applied models; then, when you want to change the form of some orders, you must / will be able to add the model of the new one or modify the existing one.
In addition, an application, as defined in TOGAF 9 , is a “deployed and operational IT system that supports business functions and services”; follows that, an MDApp can be described as an IT system that supports business functions and services, which is deployed and operational based on the model of the (thing in) business; here, the business is the target and the model of (thing in) business is the applied model.
The basic and core construct to achieve an MDApp has been abstracted, that is, the model-driven mechanism, based on it, can design and implement a variety of actual systems. For real software, the operational device of MDM is often divided into some modules, for example, modeler (modeling tools), model driver (engine), operator (or function engine) based on the model driver, etc. Figure 1. shows such a primary structure of an model-driven application system, customarily, such the software system can be called an MDApp platform.
In practice, the actual design of the platform for enterprise / business app is usually far more complex than the Figure 1, and it may be combined with different architectural styles, for example, SOA, and uses many of the relative MDM structures as multiple model-driven mechanism. In any case, MDM is always the essential core construct to achieve the key features of an MDApp.
In summary as a brief statement, MDApp is the app which running on some evolutionary applied model of the target thing. The most significant feature is to the user, that is, it achieves functions / operations which are related with the target thing (the business) on the models ; the models are able to be updated by user in operation of system. Such the feature can be summarized as a slogan “What Can Be Done Is What Can Be Modeled“, or reference to well-known acronym WYSIWYG, say “what you model is what you handle” (WYMIWYH) . What the customer buy from a software provider is no longer a business solution with so-called “best practices” but the platform and tools only, which support desired business and enterprise / business engineering. What the business is, the individual needs, are reflected in the applied models belonged to customer, thus, for a specific customer, one can say: the model is application.
It should be noted that, the target thing being modeled can even be (a part of) the system itself, for instance, the user interface (UI), appearance, configuration or structure, and so on; although running on such the model (reflection) is very interesting and may especially liked by software architect or programmer, and it certainly also a great feature for the end use too, in my opinions, however, the first significant contribution definitely is that running on the model of the thing outside the system (often called the real world), and this “a little” difference will result a huge distinction from the usual apps which designed towards fixed business functions, in the entire application life cycle and the ecosystem.
The ideas of MDApps
In practice, the ideas of MDApps are quite pertinently embodied as a rich and strong architecture, see MDApps vs. MDA and OO: from an Architectural Perspective, also Understanding Architecture.
Behind MDApps, there are indeed a series of, coherent, and consistent ideas and principles, it can be glimpsed at this post: A Roadmap of Research for Enterprise Applications. In comparison with the popular or common views in recent decades, it is indeed represented a completely different “world view” for computing. This requires more elaboration. A little preliminary discussions have presented in  (such as in the Sec. 2), and there are some more only on this blog so far, such as
- Situation for discussions about MDApps
- Human, Computer, the Real World, and Inevitable Mediating Model
- Model-Dependent Realism: Is This the Worldview of Software Engineering?
- Three Spaces for Entities and Models of Applications
- Abstraction (III) Make Long Story Short
- Cognitive Structure Triangle and Conceptions of Images, Models and Theories and An Architecture Model for Cognition, Information Systems as well…, it seems too subtle or a bit away from the topic but probably close to some essential.
- Open World and Finite Models, and so on.
These posts are really very scattered, in particular, some early writings are a little as exercises and attempts, but they are lied on a comprehensive view in my mind.
In the end, this discussion is basically in the context for enterprise / business application, just as that set by TOGAF and the situation for discussions about MDApps, that is also the starting point of our exploration and has always been the focus so far, however, we also find that, such the ideas and principles have a wider significance, for example, to the information systems in the most general sense, or intelligence.
 Almost only one of the very similar use for the term “model driven application” I’ve seen so far, is Principles for Model-Driven Applications and a few relative posts on that blog, posted by Håvard Jørgensen, in 2009. More results by search on Internet are almost all like as “model driven application development”, which are under quite different senses from this post.
 Yu, Tong-Ying. “Model-Driven Applications: Using Model-Driven Mechanism to Bridge the Gap between Business and IT.” In Advances and Applications in Model-Driven Software Engineering. Díaz, V.G. et al. eds. IGI Global, August 2013 (in press, see Recent Work on Model-Driven Applications (MDApp).
 In the era dominated by object-orientation, it must be distinguished from the OO concepts, such as Class, Object. In experience, OO architect very easy to see the similar aspects, and thus misses the difference–the most critical contribution is just related with the latter.
 The Open Group. “TOGAF (R) Version 9.” Online: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html.
 There are different ways to connect the operations or behaviors of / on a system to the target thing; the first one in this context is via humans (the users). It needs a specialized discussion.
 Note that, as a comparison with main approaches in existing MDE, it can be “what you model is what (software) you get” (WYMIWYG), the distinction is obvious (see Model-Driven Applications vs. Model-Driven Engineering, download the pdf).