The Model Driven Software Network

Raise your level of abstraction

Some division of models for enterprise applications, a sketch

A basic division of models can be determined by the objects of the models (i. e., what a model modeled). See the illustration (from my essay here). Under the subject of enterprise applications, there are two camps I called application system technical domain and applied domain (the domain the application system well be applied in) and the latter has two important states: AS IS and TO BE. Another idea is, to pick up the old concept black/white-box for a classification of models.

The entities, such as products and servers, work centers (a concept from ERP), organizations (corporations, organizational units and roles), business processes..., and the application system.

But I feel the expressions appear somewhat not very well or satisfied. On other hand, such the terms like domain, application domain, domain models are used for some specific meanings...

Your comments?


(there are some essays related to this topic in my blog)

Views: 322

Reply to This

Replies to This Discussion

What you call "App System Technical Domain", I would call "Solution Domain". The solution domain is where we keep the concepts that are related with the implementation, like a database, a file, protocols (HTTP, SOAP, etc).

What you call "Applied Domain", I would call "Problem Domain". The problem domain is where we put the concepts related to the real-world problems we want to solve, like a customer, a bank account, etc.

 

In MDA terms, the solution domain is implemented in a PSM, Platform Specific Model. The problem domain is implemented in a PIM, Platform Independent Model. Then you need to implement model transformation, to translate a PIM into a PSM, that on its turn would generate the final working code.

 

In ABSE, both solution and problem domains are implemented in Atom Libraries. Model transformation is achieved by Atom inheritance and/or composition.

Hi! Rui,

In my understanding, the terms solution domain and problem domain are separately belonged to (a part of) the app system technical domain and the applied domain, and I'm feeling that it's not suitable to be a background of my division of the models and the entities. Maybe the more suitable words for my thought should be 'field' instead of domain, simply say "technical field" and "business field"?

- App System Technical Domain

Personally, I call it mostly "(IT) System Domain", since there exist IT Systems.

 

- Applied Domain

I prefer "Business Domain" or simply "Domain" (like e.g. "Domain Model")

I don't like the prefix "Application/Apllied", since here always the "IT perspective" peeks out. Nobody who's not in IT would call his own domain "application domain", would he?

Same holds for PIM, it underlines platform independency, but obviously a platform and a dependency is in ones mind. Maybe a better expression would be PISM - platform independent system model.

 

So alltogether there's

 

- a (business) domain

- a model of that, a (Business) Domain Model (an ontological model)

- an (IT) system

- a model of that, an (IT) System Model

 

AS-IS & TO-BE are just different versions in a history to me, obviously one can become the other, and there may be many of them.

Andreas,

 

Thanks for your very apropos comment.

 

What I had in mind to using “applied domain”, is an attempt to avoid the problems of the “problem domain”, which are problem-centered and may have somewhat a tendency that leads to ignore the integrity and relevance of business. As stated on my blog (link):

“It may be reflected such a thinking: we don’t need to model the whole enterprise/business, 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.”

However, as you said, it was still standing on a IT system developer's position, so may have no substantive difference. And the “application system technical domain” seems too clumsy. :-p

 

It seems a good expression that, using such the “business domain” and “IT domain” directly, in an appropriate context.

A little of summary by me:

  • All the things involved in an enterprise application can be divided into two basic domains – referred to Andreas’ comments – may call them as IT domain and business domain. They are a basic background to discussing about enterprise applications.
  • About the concepts of Solution Domain and Problem Domain. They may be seen as a part of IT domain and business domain, roughly – it would need more discussion.
  • Thus, as the place of the system model (black-box) and application system in the figure, the intermediate region should be a focus to us: for such the topic of separation of concerns and the bridge over the gap between business and IT.
  • In much discussions about the subject, the AS IS and TO BE distinction was ignored, I want to highlight that, this is an significant understanding for some sort of applications, such as enterprise applications: an application is not mechanically inserted into the old business (AS IS) but will be an organic component of a new business (TO BE).

(from my blog)

RSS

Badge

Loading…

© 2018   Created by Mark Dalgarno.   Powered by

Badges  |  Report an Issue  |  Terms of Service