Java开发网 - My perception of enterprise applications(original)

Java开发网

您没有登录

» Java开发网 » Architecture & Framework

打印话题 寄给朋友 订阅主题

作者

My perception of enterprise applications(original)

dissip

BigCat

发贴: 240
积分: 60

于 2004-09-10 14:25

After 2 years in enterprise applcation development,I wrote some of my understanding of enterprise application and hope it will be helpful to someone. And waiting for comments.

My perception of enterprise applications part 1 overview.

The whole world evolves faster than ever before and it will become much faster in the future. As part of it, Enterprises become larger and more complex.
Then how to build software systems in such a complex and volatile environment?
In history, business and computer engineers belong to two separated world which use their own jargon. Engineers used to build software applications using their own technical constructs. This dichotomy handicapped the two worlds. The solution is to merge the two worlds by domain driven approach. (By domain, we refer to problem domain, while the software requirement is in the solution domain and the software system is in the solution (implementation) domain) That is, to use computer systems to ‘mimic’ the reality. But because the reality is infinite while the computer is just a finite state machine, it is not possible for computers to truly mimic the reality. It can only mimic a perspective that the biz is interested in. That is the domain model – an abstraction of the problem domain from a certain perspective. It is depicted as picture 1.

Then it comes two problems:
1.  How the reality and the system interact.
2.  How to model the domain.

How the reality and the system interact
There are 2 kinds of interaction
1.  Input (from the system perspective). To mimic the reality, the system must listen for events happened in reality and change its internal state to keep synchronized with the reality.
2.  Output (from the system perspective). Only input is of no value to our biz. What biz always needs is to know the current states in reality for making decision. Because, by input, the system is in sync with the reality, the system must provide a way for biz to query the internal system state.

Both interactions happen via interface. This interface includes both human interface (such as GUI) and machine interface (such as a sensor). For human interface, it is usually called the client and presentation tier. The interface’s responsibility is only to accept/listen reality events and represent internal state.

Now another questions come:
After the interface accept a reality event, how to change the domain model? How to get the required internal state from the domain model and give it to interface for presentation?
Here comes the application tier. (As depicted by picture 2)Its responsibility is
•  To populate the event received from the interface to influence the domain model.
•  Get the required info from domain model for interface.
It is called ‘application’ because it is specific to a special usage in contrast to domain model. For example, there’s a requirement to send an email to the new registered system user. User registration is handled the domain tier because it mimic a core biz reality. Email format is at the interface/presentation tier of course. The email sending is at application tier because it is only specific to this usage.

How to model the domain

This is a really complex problem. Because different people will view the different reality problems in different ways, they may come up with different model/abstraction. Model paradigms have been conceived to address certain ways people like to think about domains. There is no unique solution for all problems. Each paradigm has its pros and cons and should be best applied when the context meets the prerequisite.

The most dominant is the OO. It models the reality as a set of related object. But the reality is complex and sometimes it is more appropriate to model the domain with such non-object components as business rules engines and workflow engines. Mixing paradigms allows developers to model particular concepts in the style that fits best. Furthermore, most systems must use some non-object technical infrastructure, most commonly relational databases. Some mapping tools/adaptors can help to merge different paradigms. But making a coherent model that spans paradigms is hard, and making the supporting tools coexist is complicated.

In the following sections I will discuss the several problems in these tiers separately. (Coming soon)

dissip edited on 2004-09-10 14:39

To live is to fight.

话题树型展开

人气	标题	作者	字数	发贴时间
5996	My perception of enterprise applications(original)	dissip	4433	2004-09-10 14:25
4232	Re:My perception of enterprise applications(original)	dissip	5	2004-09-10 14:26

已读帖子

新的帖子

被删除的帖子