Logical Model

The logical model defines the business entities that will be rendered by the application and what policies and rules will be used to operate on those entities. The questions this model answers are very specific to the business for which you are writing your application. These questions include:

When should a customer be given a purchase discount?
When should inventory be restocked?
How much sales tax should be charged to an international order?

The logical model itself is made up of two relatively independent sub-models, the logical data model and the logical object model. The logical data model is responsible for documenting the business entities that the system manages (such as products, customers, and orders) and the rules for maintaining them (for example, "all new orders must be represented in the Orders table as well as the Shipping table"). The logical object model is responsible for documenting the rules/algorithms that operate on the data entities, how these rules are grouped into interfaces and classes, and how the various objects interact among themselves to solve macro level requirements. You also use the logical model to specify how each object fits into the three-tier logical services model.

How the logical model interacts with other models

As the diagram in the Enterprise Application Model shows, the user model directly interacts with the business model, the logical model, the technology model, and the physical model. The following table characterizes these interactions and gives brief examples of each.

Sub-model	How the logical model relates to it	Example
Business model	Determines how business policies can be encapsulated.	An application that must accommodate rapidly changing tax rates and rules must isolate these rules in separate, easily maintainable components.
User model	Defines the logical entities the user acts on to perform various business tasks.	Logical customer and order objects and credit checking services are needed to enable the user to carry out typical sales tasks in the application.
Technology model	Specifies the features and services that must be packaged into the chosen technology’s components.	A credit checking component must use technology capable of interfacing with credit reporting agencies.
Physical model	Determines the features and services that must be deployable using the chosen physical architecture.	A funds transfer component must be deployed on an infrastructure that supports reliable security protocols.

Since the development model permeates all of the Enterprise sub-models, there are no "typical" interactions because you must account for every design and implementation decision in the development model.

How the Internet affects the logical model

Examples of the way the Internet has affected the logical model include:

The three-tier model of separating business logic from user interface behavior has gained great momentum as businesses strive to encode business functionality onto powerful Internet application servers.
The competitive environment fostered by the Internet is also driving an aggressive push by corporations and third party software vendors to implement their new functionality with objects that can be more easily maintained and reused, improving businesses responsiveness.

You should note that for the most part, the Internet is a physical phenomenon and will not have a significant impact on the logical model of those businesses that have already moved to object oriented LAN-based development.

For more information The logical model and three-tier application design are explored in greater depth in "Defining Application Logic," in Chapter 3, "Tools for Enterprise Application Design."