Mode and architecture Reading Notes enterprise application architecture model 1

Introduction

NBuilding a computer system is not easy. As the complexity of the system increases, the difficulty of building the corresponding software increases exponentially. We are expected to overcome these difficulties only by making continuous progress in learning, learning from successful experiences, and learning from failed lessons.

n many people try to define the" architecture ", but these definitions are hard to be unified. There are two points that can be unified: one is the highest level of system decomposition, and the other is the decision that is not easy to change in the system ".

n the book is actually about how to organize enterprise applications into different layers, and how these layers work together. Most important enterprise applications are designed hierarchically in some form. Of course, in some cases, other design methods also have their own values, we will not discuss these methods in this book, but focus on the hierarchical approach because it is the most widely used design method.

n my work is mainly about enterprise applications. Enterprise applications generally involve persistent data ...... Enterprise applications generally involve a large amount of data ...... Enterprise applications generally involve many people accessing data at the same time ...... Enterprise applications also involve user interface screens for large volumes of operation data ...... Generally, it needs to be integrated with other enterprise applications distributed around the Enterprise.

NAbout business logic: I think the word "business logic" is funny, because it is difficult to find something that is more logical than "business logic ....... Tens of thousands of "one-time special cases" in real business ultimately lead to complicated business "no logic", making the development of commercial software so difficult.

N Performance concepts:
Response time The time required by the system to process an external request;
Responsiveness Different from request processing, the system responds to requests at multiple speeds (for example, displaying a progress bar when executing background tasks can improve the responsiveness of the user interface );
Wait time Is the minimum time to obtain the system response in any form (mainly reflected in the network latency of remote calls );
Throughput Is the amount of requests that can be processed within a given time;
Performance The throughput or response time is determined by the user;
Load Is a statement about the current load of the system;
Load Sensitivity It refers to the degree to which the response time changes with the load;
Efficiency Is the performance divided by resources;
System capacity It refers to the indicators of maximum load or throughput;
Scalability It measures the impact of adding resources (usually hardware) to the system on system performance (vertical scalability generally refers to adding servers, and horizontal scalability generally refers to improving the performance of a single server ).

When building enterprise application systems, focusing on hardware scalability is often more important than focusing on capacity or efficiency (purchasing new hardware is often cheaper than struggling to improve software performance ).

 

The book is divided into two parts: the first part of the "expression", from Chapter 1 to chapter 8, a brief introduction to the content involved in the book; the second part of the "Mode ", from Chapter 9 to Chapter 18th, we will explain in detail various specific modes, including the operating mechanism, usage time, and examples.

Chapter 1 Layered

When breaking down complex software systems, one of the most used technologies by software designers is layering. In the computer architecture, we can see that there are examples of layering everywhere.

There are many important benefits of decomposing the system by hierarchy:

NA layer can be understood and used as an organic whole without having to know more about other layers.

NYou can replace the implementation of a layer without changing the interface, without affecting other layers that use it.

NThe dependency between layers can be minimized.

NLayering is conducive to standardization.

NOnce a layer is built, it can be used to provide services for many services.

However, layering also has its own drawbacks: hierarchies cannot encapsulate everything, and too many hierarchies affect performance.

This book discusses three basic layers of architecture: presentation layer, Domain Layer (business layer), and data source layer. The most difficult issue in a layered architecture is to determine the layers to be established and the responsibilities of each layer. A less formal test method is to add a completely different new layer to the system, for exampleWebThe application adds a command line interface layer. If you find that you need to implement some features again in this process, it indicates that there may be some logic that should be implemented at the domain layer, it is now implemented at the presentation layer. Similarly, you can assume that the background database is replacedXMLFile Format. What will happen?

BTWBefore discussing specific layers, I personally think that it is essential to build a sound and robust system, however, in reality, for various reasons (including objective and subjective reasons, such as project scale and developer capabilities), it is often impossible to achieve a purely hierarchical architecture, this requires a slight flexibility based on the actual situation to achieve the overall optimal solution.

In this chapter, the author providesHow to determine the layered BoundaryThis method is simple but effective.

Chapter 2 Organization domain Logic

Because the domain layer is between the presentation layer and the data source layer, it is the most difficult to determine its boundary and face more challenges. I think, this is why the author described this layer as a separate chapter.

The organization of domain logic can be divided into three main modes: Transaction script, domain model and table module..

transaction script in general, it is a process-oriented model, use the sub- Program . These subprograms are responsible for obtaining user input and saving operation results to the database; Domain Model in general, it is an object-oriented model that completes the business through the interaction of various business objects, and each object clearly undertakes part of the work; the table module is similar to the domain model. The difference is that the objects in the domain model correspond to a record in the database, the objects in the table module correspond to the entire table in the database.

Each of the three modes has its own advantages and disadvantages.. Transaction scripts are easy to understand, but the more complicated the system is, the more difficult it is to maintain. Domain models are very standard, but they must be implemented purely, the main problem to be faced is the ing between objects and relational databases. The table module is between the two. Many development platforms support table modules and record-set-based programming. Therefore, it is often a good compromise.

Chapter 3 Map to Relational Database

This chapter will discuss how the domain layer can access databases. The author provides several modes: Row data entry, table data entry, activity record, and data er.

Row Data EntryMode refers to the creation of an object corresponding to each record in the database. The object provides the attributes and operation interfaces of the data;Table Data EntryIt refers to the creation of an object (generally a record set) corresponding to each table in the database. This object provides the operation interface for this table; by adding business logic to objects in the row data entry modeActivity recordsMode. This object is responsible for both basic database operations and business interfaces. When the domain logic becomes more complex, it is difficult to directly match the objects in the activity records with the database tables, these objects can be divided into business objects and data er objects to solve this problem. The data er objects still have one-to-one correspondence with the database, business Objects use the interfaces provided by the data er object to perform data operations.Data er Mode.

According to not strict observation, the overhead of relational database ing is probably the total overhead of program development. 1/3 And will continue to the maintenance stage. . In the course of development, object-oriented databases have emerged, trying to solve these problems. However, due to its maturity and risk avoidance, most projects do not use it. On the other hand, O/R The ing tool provides a better solution to this problem. O/R You can purchase or develop the ing tool by yourself. I think many developers are doing this.

Some discussions on reading data: The author regards the method of reading data as a finder. Where can I place the finder? After the discussion, a general reference method is obtained: the finder can be put together with the table data entry object. If the row data entry is used, the finder object should be created separately.

When talking about object-relationship ing, most people talk about the structure ing mode, which is used in the ing between memory objects and database tables.. The author has made some general discussions on the issues of relational ing, inherited ing, and database connection pool.