"Enterprise Application Architecture Model" (POEAA) Reading notes

Original Address:"Enterprise Application Architecture Model" (POEAA) Reading notes Gianzilong (Technology-5013 What is architecture

• Rolph Johnson argues that architecture is a subjective thing, a shared understanding of system design by expert project developers
• The architecture includes decisions that developers want to make as early as possible, because they are hard to change for developers to see.
• If you find that certain decisions are not as difficult to change as you think, then it is no longer relevant to the architecture
• Understanding: B/S (SmartClient, c/s) architecture, DotNet architecture, Java EE architecture

Features of enterprise applications

1. involves persisting data
2. Many people access data at the same time
3. User interface with extensive operational data
4. Integrate with other applications that are scattered within or around the enterprise
5. The concepts of heterogeneous systems contain inconsistencies
6. Business logic is usually the least logical thing
7. Enterprise applications are not all large, but they may provide tremendous value to the enterprise.

· Performance: In many cases, adding more servers is cheaper than adding more programmers, and if you increase the performance of the server, it means that the scalability of the application is good.

· Layering: The upper layer is defined by the lower layer of the various services, and the lower layer is not ignorant of the upper layer; a layered flaw is that it cannot encapsulate everything, so it can lead to cascading changes, too many layers that affect performance; the difference between layer and tier is that tier may mean more physical separation

Brown Layered Model

presentation Layer >> control layer >> domain layer >> data Map layer >> data source layer

Core java EE layered Model

Customer Layer >> presentation layer >> Business Layer >> Integration Layer >> resource tier

MS DNA Layering model

presentation layer >> business Logic Layer >> data Access layer

Marinescu Layered Model

Presentation Layer >> Application Layer >> service layer >> domain layer >> persistence layer


· Domain Model: Use objects of different responsibilities to work together to solve business problems, rather than working with data through transactional scripting

· Impedance mismatch: Mismatch between the object model and the relational database, usually through object-relational mapping (ORM)

· Four features of a software transaction

1. atomicity: Either all succeeds, or all rolls back

2. Consistency: Resources should not be destroyed when a transaction starts and completes

3. Isolation: The impact of a transaction should not be seen until it is successfully completed

4. Persistence: Transactions do not lose changes because of any crashes

· Isolation level of the transaction (high and low)

1. Serializable: Full isolation, the result of concurrent execution is the same as the result executed sequentially in some order

2. Repeatable READ: Allows for phantom reading, the updater inserts some elements into the collection and reads only a subset of them.

3. Read committed: Allow non-repeatable read, all submitted data can be read

4. READ UNCOMMITTED: Allow dirty reads, allow READ UNCOMMITTED data

· Session state: Stateless objects are a bad design; You can use stateless servers to implement stateful sessions, and if you have many sessions that are idle, consider using a database store session, or a server session if you need frequent access to sessions

· Distribution strategy: The first Law of distributed objects: Do not use distributed objects; the second law of distributed objects: saving the use of distributed objects

The domain logic model is divided into four modes of object script, domain model, table module and service layer.

Many designers like to divide business logic into two categories: domain logic and application logic, which are only relevant to the problem domain, while the latter is sometimes referred to as workflow logic

1. Transaction scripts

By using SQL statements or stored procedures to return a recordset, the recordset is passed between the layers of the system and can be updated as necessary by updating the recordset, using an SQL statement, or a stored procedure
Transactional scripting is simple, often applied in small projects and systems, but business logic is becoming more complex, and it is increasingly difficult to maintain good design with this pattern, because there are a lot of SQL statements and commands in the program, once the data structure changes or the system needs to be modified, There may be many difficult problems to discover

2. Domain model

The domain model is the object model of the domain where the behavior and data are merged, and the domain model creates a network of interconnected objects, each of which represents a meaningful individual, possibly as large as a company or as small as a single line of orders.

Simple domains can use activity records, which are simple single data records and the corresponding patterns of individual objects, one object corresponding to a table in the database

The complex domain model needs to use a data mapper, which may use inheritance, policy, or other design patterns, a complex network of interconnected fine-grained objects, which we often see: multiple classes interact to accomplish simple tasks

In object-oriented technology, a continuous pass from one object to another can pass the behavior to the most qualified object, and it eliminates many conditional-judging behaviors.

The main point of the domain model is the existence of hidden databases

3. Table Module

A table module is an instance of the business logic that processes all rows in a database table or view

Table modules are used in conjunction with objects by strongly typed or weakly typed datasets, using primary keys to query data, which is a large number of patterns used in. NET, mainly using primary key, semi-object operation data---is semi-structured because the objects used are basically just behaviors. Perform a specific action by passing in parameters or query a recordset, with virtually no data hosted

In. NET, this pattern is popular because it is easy to bind and interact with the UI

4. Service Layer

Define application boundaries through a service layer, set up a set of available operations in the service layer, and coordinate the response of the application within each operation

A service layer is a pattern that organizes business logic, somewhat similar to a business look, and WEB service typically serves as the role of the service layer

The service layer can be implemented by the domain appearance method and the action scripting method, where the service layer appears as a collection of thin appearances above the domain model and does not contain the business logic in the class that is responsible for the appearance; In the action script method, the service layer consists of a relatively complex set of classes that directly implement the application logic. But delegating domain logic to the encapsulated domain object class

The interface of the class of the service layer is coarse-grained and suitable for remote invocation. However, at the outset, we should only design a service layer that is called locally, and then add a remote look at the service layer when a remote call is required.

The correct goal of concurrency management is to maximize the correct access to data while reducing conflict
There are two types of offline concurrency modes: Using optimistic offline locks, using pessimistic offline locks

Offline lock can be understood as a non-server-managed lock, or a self-managed lock, where the application registers the lock in the appropriate place, obtains the data, then goes offline and takes the data offline, and other applications determine whether to perform concurrent operations by detecting registered locks

1. Pessimistic offline lock

Pessimistic offline locking assumes a high likelihood of session collisions, limiting the concurrency of the system
When the requirement for inconsistent reads is not high, the first choice is to use exclusive write locks (no additional read locks can be added, and of course, write locks are not); If you must read the latest data and don't care if you want to modify it, you should use an exclusive read lock (you can no longer add any write locks, but read locks are allowed). In combination with the above two, provide the restriction of the mutex read lock, and the concurrency of the mutex write lock is called read/write lock---Read/write lock mutex cannot be added simultaneously, but concurrent read lock is allowed
Steps to build a pessimistic offline Lock: Decide which lock to use >> build a lock Management object >> Define the process of using locks for business transactions
To exempt a lock management object from deadlock when it throws an exception when the lock is not available, rather than waiting for the lock to be released
Pessimistic offline Lock as a supplement to optimistic offline lock, should only be used when it is really needed

2. Optimistic offline lock

Optimistic offline locking assumes a small likelihood of session collisions, making it possible for multiple users to process a single piece of data
Conflict detection and transaction rollback to prevent conflicts in concurrent transactions
The essence is that by comparing the version number in the session to the version number of the current record data, the version number increases after the transaction is successfully submitted, or if all fields are checked in an updated SQL statement, you may not need to add a version field to the database, but can result in a performance penalty
Optimistic offline locks must be self-checking to prevent inconsistent reads
An efficient merge strategy can make optimistic offline locks very powerful, and when conflicts occur, merge policies can merge changes and resubmit

"Enterprise Application Architecture Model" (POEAA) Reading notes