Enterprise Application Architecture Model

(Translator's order)

"Each pattern describes a recurring problem around us and the core of the solution to the problem. In this way, you can use this solution again and again without repetitive work ." ---- Christopher Alexander

Moves can be ever-changing, but the solid and profound "internal strength" is consistent;

(Preface)

For books on the universality of software architecture, I recommend [POSA]-"pattern-oriented software architecture ";

The core of iterative development is that the software should be delivered as long as it is useful to users, even if it was not completed at the time;

(Introduction)

Most important enterprise applications are designed hierarchically according to some form;

Enterprise applications:

-Enterprise applications generally involve persistent data;
-Enterprise applications generally involve a large amount of data;
-Enterprise applications generally involve multiple users accessing data at the same time;
-Enterprise applications generally involve user interface screens with large volumes of operation data;
-Enterprise applications are rarely independent and usually need to be integrated with other enterprise applications distributed around the enterprise;

Enterprise applications are diverse, and different problems may lead to different solutions;

When building enterprise application systems, focusing on hardware scalability is more important than focusing on capacity or efficiency;

In general, purchasing new hardware is cheaper than modifying old software;

The key point of the pattern is that they originate from practice;

One of the keys to the use mode is that you cannot use it blindly;

Each mode is relatively independent, but not isolated from each other. Sometimes they interact with each other;

The Pattern provides a set of vocabulary for the design, which is also why the pattern name is so important;

(P12)

When breaking down complex software systems, one of the most widely used technologies of software designers is layering;

When we consider a system from a layered perspective, we can think of each subsystem as being organized in the form of a multi-layered cake, where each layer relies on its underlying layer. In this way, the upper layer uses various services defined by the lower layer, while the lower layer does not know anything about the upper layer. In addition, each layer hides the details of its lower layer from its upper layer;

Of course, not all layered architectures are isolated, but the vast majority are opaque or at least almost opaque;

(P15)

Depending on the problem, select a suitable separation method, but remember to do some form of separation-at least at the subroutine level;

(P16)

As long as it is possible to use the web expression, the fat customer method is used only when necessary;

(P19)

The use of "Domain Model" rather than "transaction script" is the essence of "theoretical system transformation" that object-oriented programmers advocate;

(P20)

The value of "Domain Model" is that once you master it, you can use many ready-made technologies to better organize increasingly complex domain logic;

(P21)

Once you get used to the "domain model", you can use it well in the future to benefit your life;

In many aspects, the "Table module" is an intermediate area of the "transaction script" and "Domain Model;

(P22)

The more experienced the development team has, the more I tend to use the "domain model ";

(P23)

Transaction scripts, domain models, and table modules are not mutually exclusive. In fact, it is common to use a "transaction script" to process part of the domain logic, and use a "Table module" or "Domain Model" to process the remaining part;

A common method for processing domain logic is to divide the domain layer into two layers. The "service layer" is independent and placed on the underlying "Domain Model" or "Table module. The interaction between the logic and the domain layer passes through the service layer, just like the application's API;

If a service layer is set up, the number of placement actions is a crucial decision:

-In a minimal case, the "service layer" is only an appearance, and all actual behaviors are in the lower-layer objects. What the "service layer" does is to pass the upper-layer calls to the lower-layer. In this case, the "service layer" provides an easier-to-use API because its methods are generally organized according to use cases. At this time, it also provides a very convenient entry point for adding features such as transaction encapsulation and security check;

-The other extreme is to place most business logic in the form of a "transaction script" in the "service layer. Lower-level domain objects become extremely simple. If the lower layer is a "domain model", the objects in the model correspond to the database one by one. Therefore, you can use simple data source layers such as "activity records;

(P26)

Clear separation of SQL and domain logic is quite beneficial;

(P2)

If the domain logic is very simple and the class and table are very consistent, it is enough to use "activity record;

If the domain logic is complex, "Data Er" is needed;

(SpO2)

Try to use a pre-compiled static SQL statement instead of compiling dynamic SQL every time;

(P62)

The Local interface is preferably a fine-grained interface. Fine-grained interfaces are very good because they comply with the general object-oriented principle, that is, to segment objects as much as possible, so that we can combine and overwrite these objects in different ways to expand the design in the future;

(P63)

XML-based Web Service is used only when the system cannot use its own remote call mechanism;

(P77)

The "transaction script" is better than the simple one. For applications with only a small amount of logic, using this mode is natural and will not bring too much overhead in terms of performance or understanding;

(P81)

The degree of coupling between the "Domain Model" and other layers in the system should be minimized;

(P83)

To be familiar with the "Domain Model" requires practice and training, but once I have mastered it, I find that, in addition to solving the simplest problem, few will use the "transaction script ";

(P86)

The great value of the "Strategy class" is that it provides some well-encapsulated insert points for application expansion;

(P87)

In object-oriented technology, behavior can be passed to the objects that are most qualified to be processed through continuous transmission from one object to another. It also eliminates many condition-based judgment behaviors;

Similar Condition judgment statements can be extracted into the object structure;

(P88)

One of the key ideas of Object-oriented thinking is to bind data with the behavior of operations on the data;

(P94)

The "service layer" defines the application boundaries and available operation sets that can be viewed from the interface customer layer perspective. It encapsulates the application's business logic, transaction control, and response coordination in its operation implementation;

The interfaces of the "service layer" class are coarse-grained. In terms of the interface granularity, the "service layer" class is suitable for remote calls;

(P96)

The design concept of "service layer" comes from the application boundary model;

The advantage of "service layer" is that it defines a public set of application operations, which can be used by various customers, and the service layer coordinates the application response in each operation;

(P99)

The "service layer" design model lays the foundation for encapsulating the application's business logic, implementing and supporting different customers to call these logics in the same way;

(P101)

The "table data entry" interface is very simple. It generally includes several methods for searching and updating, inserting, and deleting data from the database;

(P102)

"Table data entry" and "Domain Model" are rarely used together, because the "Data Er" Better separates the "Domain Model" from the database;

The "table data entry" can be used well together with the "Table module". It generates a record set data structure which is processed by the "Table module;

(P103)

In the. NET environment, when a large amount of information is operated, but you do not want to transfer all the information to the memory at one time, the data reader is a suitable choice;

(P107)

It is hard to tell the difference between "data entry" and "activity record". The key to this issue is whether there is any domain logic. If yes, it is an activity record ". The "row data entry" only contains the database logic but does not have the domain logic;

(P275)

The overhead of inter-process invocation is higher than that of intra-process invocation-even if both processes are on the same machine;

(P340)

. Net has a good support mechanism for value objects. in C #, it is marked as a value object by declaring an object as a structure rather than a class;

(P352)

If you rely on external resources that are completely out of your control, the software project is usually frustrated;

Enterprise Application Architecture Model