In Some Classification of Models for Software Applications, I explained some classification on the models which are relevant to software applications. Some of the models and domains were shown in the Fig. 1 of the essay. I will try to illustrate it more but before starting, do some improvement for the expression firstly. See the new Fig. 1, it is re-drawn on the original figure, and changed the name “application system domain” to “application system technical domain”. And furthermore, I will to shrink the range into enterprise applications.
The new Fig. 1 presented a whole triangle of relationships among application system and black/white-box models. It was discussed in another essay Modeling on Black/White-boxes, and Abstract Level. So, here, we will starting from the other part of Fig. 1.
Domain models and entities
Typically, a comprehensive enterprise application system would be involved in many matters — from an information modeling perspective, generally called ‘entities’ – such as products and servers, work centers (a concept from ERP), organizations (corporations, organizational units and roles), business processes and so on. Notice that, the application system itself will be a part of the enterprise, and associated to others entities on an equal basis, see Fig. 2. Of course, these entities have complicated relationships/interactions each other, they are constituted a complex, open system.
One of important message from this illustration is, a black-box model of system will belonged to the applied domain (TO BE), as well as the entity of the application system, and we may be need to model many of entities such as product and server model, work center model, organization model, business model, and so forth, not only the application system, though we have only the purpose to developing an application system.
In the applied domain (AS IS)
Look at the applied domain (AS IS), see Fig. 3, there are no the application system yet. The only thing I want to mention here, is that it is not a linear combination from “AS IS” (plus an application system) to “TO BE”. The entities (the business) will be changed while the system be applied into the enterprise.
The primary thinking for this, may be traced back to two decades ago, Michael Hammer‘s famous paper, “Reengineering Work: Don’t Automate, Obliterate”, Harvard Business Review, July August 1990.
Based on the thoughts like in this discussion, when one talks about domain models (somewhat a vague concept, isn’t it?), I will ask, what entities you modeled? Is all the related entities (and the business) with the application system as a black-box, or the functions of the system only? What facts the domain models captured? AS IS or TO BE? Who is able to design and describe the “TO BE” but not only the system? These are very hard questions.
By the way, to talk about the problem domain. It may be reflected such a thinking: we don’t need to understanding/describing the whole enterprise/business but only the part related to the system we want to develop. But unfortunately, there may be not a clear boundary, or exact criteria to demarcate it, because the requirements (problems) and the possible solutions are naturally various and changeable. Moreover, the system will only be existed in the TO BE domain which is in some imagination in developing time. In other words, an applied domain (or problem domain) may be hard to be demarcated around the application system it self, it may be had to be divided by the business. So, this is also one of the reasons, we had to grasp some approach to modeling the whole enterprise/business.
THINK IN MODELS 