First, what is architecture
About what is architecture, the industry has never been a uniform definition. Martin Fowler in "Enterprise Application Architecture" also did not give its definition, unified content can only mention two things:
The highest level of system decomposition;
Decision system is not easy to change.
"Software Architecture," a book summary is defined as consisting of school and school decision-making framework will:
Composition faction: = architecture + interaction components: a software system architecture of the system is described as between computing components and component interactions.
Decision to send: = important decisions set architecture: a collection of decisions made in some important aspects of the software architecture.
The concept was originally derived from the architecture of the building, so I think from the perspective of the building to think about this problem. Wikipedia, the schema, that Architecture is defined as follows:
Architecture is both the process and the product of planning, designing, and constructing buildings and other physical structures.
Simple translation is: architecture planning, design and construction of buildings or other physical structures of the process and results.
From the above definition, first of all, the ultimate goal is to output architecture building or other physical structures, structures can be just a house, it can be an estate, or a district, business district, or even a city . The larger the structure, the more complex its structure inevitable.
Secondly, the need to go through three stages before the output Buildings: Planning (planning), design (designing) and building (constructing). These three stages is actually the core of the architecture. For example, developers want to build a residential district, first affirmed the district to have an overall plan of it: the construction of a cell site, the contents of construction scale, construction investment is estimated construction period and so on. Next, it is necessary for all aspects of cell design, the highest level should be the overall layout design district, split open, then that is the real estate design, green design, design a variety of facilities and so on, and then refine down is a variety of apartment design, real estate within the district and various aisle design and so on. Finally, the construction phase is the construction phase, and is all the ideas into phase before the actual building. That framework includes the above process and results.
So, if the building will be replaced by software, it would become the definition of software architecture: the software architecture planning, design and construction of software process and results.
Accordingly, the ultimate goal is to output the software architecture of the software can be a App, can also be a platform, such as SaaS, PaaS, BaaS and so on, and even the wisdom of such a large urban ecosystem, the Earth people know more large and complex system, the more difficult architecture. Planning stage more consideration is demand software, including business functional requirements and technical non-functional requirements such as reliability, scalability, maintainability and so on; at this stage architecture system architecture generally. Design phase of the work is split more refined to meet the diverse needs; this stage architecture is generally logical architecture. The main stage is constructed to implement and deploy the software; this phase architecture typically physical architecture.
Second, the architecture and planning
Architecture and planning to do? I think the main border is planned next phase of architectural design. The impact of border infrastructure, in fact demand. Demand constraints on the formation of architecture, which also formed the boundary of architecture. It can be divided into three categories: business requirements, functional requirements and quality requirements.
(A) business needs
Business demand is the highest level of demand, its meaning, I am inclined to agree with Wen Yu explained mentioned in the "Software Architecture Design" in: its focus on the customer base, the corporate status quo, future development, budget, project, development, operation, maintenance commercial factors, including the entire software life cycle involved, including the commercial level objectives, expectations and restrictions. General business needs relatively large impact on the architecture, the architecture produced on commercial considerations will be more restrictions in this list some of the more common ones:
Time to market: time to market defines the system from design, development, testing the boundaries of time to market. Before I had a follow up to vertical application, time to market market requires students before the new school, or they will miss the best period of the promotion, development time reserved for only two months. So, we had most of the elements before reuse projects, including some of the modules to reuse the service side, including the client's architecture and interface. Of course, under normal circumstances, it is not reserved for such a short time to develop, but it will not be particularly long. Architect based on the length of time required to balance the needs of all aspects, good architecture selection.
Cost estimates: cost estimates to define the boundaries of the resource can be used. Development costs of different architectures certainly different, to meet the demand for more functionality and more quality requirements of the infrastructure costs are also higher, with limited budget and can only weigh a variety of needs, priorities important to meet the high level of demand.
Situation of Human: 100 development team and development team of 10 people, software architecture will be very different. In addition, the development team personnel whose skills will be an impact on the architecture selection. For example, the team no one would use React Native, it is not appropriate at this stage as the technical basis for selection React Native App architecture.
And peripheral systems integration: When you need to integrate with external systems, need to seriously consider an integrated approach, especially when older peripheral systems, integration may be more difficult. In addition, the uncontrollable factors peripheral systems more generally, therefore, uncontrolled risk framework to deal with these requirements is also relatively high.
Open: closed proprietary systems and open systems architecture requirements are also different, if you select a system open, and that the quality of the infrastructure requirements are higher, security, scalability, performance and other quality attributes should be closed when the ratio high.
Target market: the target users 100,000, 1,000,000, 10,000,000, different levels of the target market, the architecture is quite different. In addition, specialized vertical market and the mass market, and architecture is also different, larger niche markets typically use planning product line.
Multiport Support: Now supports universal mobile terminal Android, iOS, Wechat, management usually end supports PC Web, if the management side also to support Android, iOS, Wechat, or mobile side and the management side would go on to support WindowsPhone, Blackberry, and even then support VR, we need to invest more time and manpower, but also need to make corresponding adjustments architecture.
Expected lifetime of the system: from the subjective to say, no one wants the system can survive for a long time, but the longer survival means that the system can be modified, scalability, portability and other needs higher. However, due to constraints of time to market, cost budgets, coupled with rapid changes in the software itself, so, objectively, generally do not expect its lifetime is too long. When the system can not meet the increasing demand, basically solved by reconstruction.
Phased plan: every major platform system is generally done in stages, so the early stage of architectural design need to consider characteristics of a good reusability, extensibility, scalability, portability and so on. But because each stage after a market-proven, demand is likely to change, so they can not be over-designed, otherwise it will cause a waste of design, may also increase the difficulty of a subsequent stage architecture adjustment.
International: If you take the international route, we must consider that the architecture is good support for multiple languages.
Competitors: Excellent product than its competitors, it would have to outdo each other in a number of key functions or quality, but also means that infrastructure in these areas need to invest more.
Laws and regulations: for example, for some keywords you want to filter mask, this is heavenly unique, I understand.
Diverse business needs, and some demand may also contradict each other, for example, time to market and cost estimates and will be expected lifetime of the system may conflict, the longer the expected lifetime of the cost will be higher, the need to invest time will be more, then it is possible to delay the time to market. Therefore, do architecture and planning, must distinguish clearly what the needs are to be met, to what extent can meet, trade-offs between the various demands. In addition, because of commercial demand is the highest level of demand, therefore, with respect to the functional requirements and quality requirements, priority is generally relatively high.
(B) functional requirements
It describes the functional requirements of the system should provide services, including services for users, including services for other systems. The architecture is mainly functional services, and basic functional requirements related to the specific business. Therefore, to do the functional requirements of this framework, it is necessary to know enough about the business, so as to better abstract modeling. Of architecture and planning functional requirements, mainly to establish business domain model. After the domain model laid down, the next stage of the design must be consistent with the domain model.
And before the functional domain modeling needs, the need to sort out priorities under demand. Because the affected business needs, functional requirements also need to weigh. For example, time to market tight, low-cost budget, human resources are not sufficient in the case is very functional requirements can not be more than less. The need for integration with peripheral systems time, this also means that some functions do not need to achieve a; however, if the peripheral system can not fully meet the demand, you also need to realize the needs of their own and then missing. Therefore, at this stage what features need to meet the demand? We need to meet and to what extent? In order to more effectively carry out field modeled after these two issues identified.
The main areas of modeling is to analyze the relationship between the domain model and understand each model. Or directly use an example to illustrate. Suppose now do a support O2O (Online To Offline) electronic business platform, the following are a few key functional requirements after combing:
Businesses can publish product platform, the entity may be commodities, commodities can also be a service.
Physical commodity support express delivery service can only commodities exchange to the merchant store consumption.
The user must provide shipping information when purchasing entity commodities.
Corresponds to the user generates an order to purchase each product.
Users buying a physical commodity, you can see the merchandise logistics information.
When the user purchases a commodity service, you can use the order of redemption code to redeem merchant stores consumption.
According to the above requirements, you can get the initial concepts related areas: business, trade, physical commodities, services, commodities, logistics information, stores the user, receiving information, order, exchange information. After clarify the relationship between these concepts art, the art can be similar to the following model view:
Of course, this is just a small example, the domain model will actually much more complex than this example. After the domain model to determine the system how many businesses, how the relationship between the concepts in various fields on a clear picture.
(C) the quality requirements
Quality requirements are three types of demand, demand the lowest level, but it is most architects are most concerned about. Overview of so many technical architecture, you will find that most are designed to solve a certain quality or attribute optimization problems.
Quality attributes common are the following:
Performance (Performance): performance is undoubtedly a very important feature, especially in the case of limited computing resources. But without too much pursuit of high performance, at the expense of other more important features.
Security (Security): safety and performance generally mutual restraint, the most obvious example is HTTPS, use HTTPS improves security, but the performance will be sacrificed. It's difficult to meet the high security and high performance, and therefore the need to balance both properties based on specific needs.
Availability (Availability): It was also known effectiveness, generally defined as: Availability = System uptime / (uptime + system fault repair time). This definition describes the availability and systems-related failures, failure rate, availability is low, failure rate, availability was high. In addition, high availability also describes the system of fault repair time is very short.
Ease of use (Usability): ease of use and availability of easily confused, concerned about the availability of the system for a long time incapable of trouble-free operation, and ease of use is concerned about is the system easy to use capabilities.
Robustness (Robustness): under abnormal conditions caused by defects, also referred robust, fault tolerance, the system refers to a user in the event of illegal operation, or hardware and software, the system can still running ability. For example, the system input errors, disk failures, network overload or intentional assault case, can not crash, do not crash, is the robustness of the software.
Scalability (Scalability): Scalability is increased when the amount of user data volume and ability to maintain a high quality of service system. For example, when the concurrency of 1W, the response time is 1 second, that if the increased concurrency 100W, simply by increasing the number of servers, without the need to modify the code to reach the response time is still 1 second, it shows the high scalability of the system.
Interoperability (Interoperability): Interoperability reflects the degree of difficulty of exchanging data with other systems and services in the system.
Scalability (Extensibility): also known as flexibility, reflects the system's ability to respond to change. In the software development process, the demand for change is common, especially in the mobile Internet era, change is very frequent, and therefore, scalability is a demand for quality mobile Internet product key consideration.
Intelligibility (Understandability): intelligibility refers to developers through source code and related documentation for ease of program functions, structure and mode of operation. Comply with generally good development standards can be improved intelligibility. In addition, the single responsibility principle used properly, can greatly improve the intelligibility of the so-called "simple is beautiful", only a simple easy to understand.
Testability (Testability): Simply put, testability is to test and diagnose software errors in the degree of difficulty. For example, ease unit testing. If the program contains a complex process logic, data structures, module relationship, testability of the design has become more important.
Reusability (Reusability): reusability indicates the degree of difficulty of a software component that can be used in other programs. When a component typically requires disengagement of the components into a common, relatively high reusability it will be required.
Portability (Portability): portability indicates the degree of difficulty of the software system from one operating environment to a different operating environment.
Maintainability (Maintainability): Maintainability refers to the understanding, correct, change and improve the software's ease. I think the most important is to ensure maintainability characteristics of a software system capable of long-term survival, not one. A poor maintainability of the system, over time, continue to become indeed affect the whole body, it becomes unmaintainable, announced only slowly perish.
Ideally, no one wants all properties are high quality, but no one knows this is impossible. To improve the quality of larger more properties to achieve the difficult and costly need to pay. Moreover, there are different constraints relationship between quality attributes, such as improved security, it will reduce the general performance; improve performance and may also reduce the maintainability. Therefore, in the actual doing architecture and planning must be weighed against the priority among quality attributes based on specific needs.
Third, architecture thinking
The architecture here that thinking means thinking when the highest level of architectural design, such as: process-oriented, object-oriented, aspect-oriented, service-oriented and so on.
1, process-oriented (Procedure Oriented)
Process-oriented design idea is to break down the problem into one step, one step after step in accordance with the Executive, the problem is solved. Each step is a subroutine, a module may also be referred to as a sub-process may continue finer split into more sub-processes. Accordingly, the process is a process for the design of the core analysis, functional decomposition, generally top-down, stepwise refinement of the decompositions. A large program can be decomposed into a plurality of sub-programs then broken down into a plurality of large modules, the module then broken down into a large plurality of small modules, ultimately decomposed into one function.
In this example I would like to borrow a chess battle, example comes from a very old article: Architect of the road (4) --- Detailed object-oriented. The following is a flowchart of a process for using battle design ideas decomposition:
Each of the above processes were used to achieve the function, the problem is solved.
Process for the two main advantages: First, the process clear and simple; Second high performance. In particular performance, which is why a lot so far microcontroller development, driver development, system development or other hardware-related software and hardware for high performance requirements of the program are still in the design and development of process-oriented manner.
Process-oriented shortcomings are obvious: First main too, the module main tasks undertaken imbalance; second is difficult to expand a function, leading to its scalability, reusability, maintainability opposing relatively poor; Third, the link between the upper and lower level module is too close, high coupling, the module is also difficult to reuse.
2, the object-oriented (Object Oriented)
Process-oriented thinking is "how to do", focused on the implementation details; and object-oriented thinking is "who will do", focused on the abstract objects. Encapsulation, inheritance and polymorphism and other characteristics of the object, let us closer to the real-world way of thinking about programming. The procedures for object-oriented easily achieve better separation, a corresponding scalability, reusability, maintainability will be higher, but at the same time some performance sacrifice. However, because the hardware is developing rapidly, so the point of sacrificing performance that's not what it is.
Object-oriented design difficulty lies in the abstract, abstracted from the problem domain objects one by one, and find out the relationship between them. Fortunately, there are a lot of design patterns SOLID principles and guidance on how we can better design. There are also field-driven design methodology to guide how we conduct domain modeling.
Examples of chess or battle, object-oriented design ideas may be three abstract objects:
Players: Consistent responsible for the line moves, both red and black behavior.
Board: the board is responsible for drawing pictures.
Referee: is responsible for determining the child to eat, such as fouls and winning or losing.
FIG relationship among the following:
After the target line chess players, chess board chessboard screen refresh objects according to changes in the layout of the pieces, the referee is the object of the chess game is determined.
3, facing the section (Aspect Oriented)
Aspect-oriented, that is, AOP, is an extension of object-oriented, object-oriented in order to compensate for the limitations. Object-oriented design is mainly abstract encapsulation of business, but the content for other than business, such as logging, permission checking, transaction support, etc., in the absence of AOP, the only code that implements these functions scattered in all object hierarchy but the core business functions of these codes with the spread of the object is not any relationship. This approach has also led to a lot of duplicate code, and difficult to reuse. AOP is to solve such a problem arising, those unrelated to the business portion is separated, so as to cross the surface of the injection system, thus reducing code duplication, to reduce the degree of coupling, to enhance scalability and maintainability.
The logging permission checking, transaction support, and so the use of cross-cutting technology independently into one service modules, also known as "cross-section", so you can use these business-related services decoupled from the core business , the system can be divided into two parts: the core business and general services. The core business is still using the object-oriented ideas to design, universal service can be implemented using aspect-oriented thinking.
Spring AOP to the extensive use of technology, OkHttp Interceptor is also a realization of AOP design. Many scenes can be used to design the idea of AOP, such as adding consistent Http Request Header, adding a unified login authentication, add a unified cache, add a unified error handling, and so on, as long as the basic point is the common functionality can be used AOP the idea to design and implement.
4, service-oriented (Service Oriented)
Whether or SOA services now popular micro-architecture, are based on a service-oriented way of thinking. When it comes to service-oriented, you need to understand a concept: Monolith, also known as single architecture. In the absence of SOA thinking, all the features of the software will be integrated into a separate package, and then deployed on a single platform. For example, in the J2EE platform, a software system will eventually be labeled as a WAR package includes all the features, and then deployed to the Web container. To expand, then be deployed to implement multiple Web containers by copying the WAR package. In this way, if the program needs to be changed, no matter how small changes, you need to repackage the new WAR package and replace the old WAR package all the Web container.
Service-oriented architecture is thought to separate the different functions of the system as a separate application or component, referred to as service, different services deployed in separate containers, lightweight communicate through some interaction mechanism between different services , such as HTTP, RPC like. In this way, compared to the monomer structure, function between loosely coupled service obviously, expansion will be a lot of flexibility. Furthermore, different services can also use different programming language, deployed to different platforms.
Whether it is process-oriented, object-oriented, aspect-oriented or service-oriented, the most essential difference is that the different angle of approach. In practical applications, it will not only use a framework of thinking, but considering the different aspects or different levels of the system may use a different architecture to think about thinking. For example, a large complex system, you may use a service-oriented architecture thinking to a whole range of services dismantling, core aspects of business services may be modeled, general service function or use aspect-oriented architecture reuse object-oriented architecture thinking thinking to design, of course, the transaction process is the use of process-oriented architecture most intuitive thinking.
Fourth, the architectural principles
From the thinking process-oriented architecture, service-oriented to the present, the future does not know what there will be new ways of thinking. But no matter what kind of way of thinking, there are some commonality of architectural principles that can guide us on how to design a suitable architecture. On the other hand, architecture design, whether it is process-oriented, object-oriented, aspect-oriented or service-oriented, without exception, are mainly in complex systems break down. So, accordingly, we need to think about three questions: What are decomposed into? How to decompose? Decomposition to what extent? Correspondingly, there are three important principles can provide guidance for the answers to these three questions.
1, the principle of separation of concerns
The main part of the principle of separation of concerns is to solve complex system into which parts of the problem, break out of that concern. Process, object, cut, service, just break down the angle (also concern) is different. The complex problem of decomposition depending on the focus of a plurality of relatively simple problem, then for each simple subjects separately, this is the separation of concerns. After separation, relatively independent of the respective point of interest, the change in each point of interest not substantially affect other concerns, even if the need to change, with the change is small. When the need to expand, the impact will also be minimized.
Separation of concerns, the most difficult is how to identify which concerns there. To identify what the focus needs to be different complex systems all aspects of abstraction as a concept model with clearly defined boundaries, or the "object" or as a "component", or "cut" or "service" to the complex problem into a relatively simple problem.
Different dimensions can have different separation scheme. In addition to the above-mentioned process-oriented, object-oriented, aspect-oriented, several other dimensions for different angles of thinking services, there are shown in the following figure, which is taken from FIG. "Software Architecture Design" a book [2.1 .1 separation of concerns] a way:
FIG respectively separated from the functional responsibilities, versatility, different dimensions in particle size. Isolated from responsibility dimension, can be divided into three tiers: the presentation layer, the business layer, data layer, corresponding concern is this: data display, data processing, and data management. Further, the data layer may also be further separated into a network layer and a buffer layer. The dimension of versatility, the common portion can be separated portions general technology, art, part of a particular application. In general, the use of the frame could be used in a variety of general partial separation. Particle size from the viewpoint of the dimension, is nothing more than a complex system of separate subsystems, and then separated into different modules, subdivided into different classes.
In practice, not only it uses a dimension, but considering the multiple dimensions, different portions of different dimensions using separation schemes. For example, perhaps, on the whole by separating responsibilities multi-layer structure, then, at some level and then separated according to particle size, for example, the business service layer is separated in different modules. Further, different generic part will be isolated, for example, permissions to the generic part of the generic part of logging technology field are separated.
2, the high cohesion and low coupling principle
How should the system break down? Or how should the separation of concerns? Coupling the high cohesion and low principle can provide guidance for the design problem.
Cohesion refers to the closeness of the features and elements inside the module, and the coupling means is the degree of association between the modules and the module.
Good cohesion can be divided into more of: poly function, the sequential polymerization, the polymerization communication, over the course of polymerization, the polymerization time, the logical cluster, the chance polyethylene. Functional cohesiveness is the strongest best cohesion of the elements work together to complete a single function within the module, these elements are closely linked, indispensable. Cohesion refers to the order, the individual processing elements and the module is closely related to a function, and these processes must be performed sequentially, after the input element of the one processing element output is typically a treatment before. Cohesive order cohesion is relatively high, but compared to the poly function, the drawback is relatively badly maintainability. Occasionally it is the weakest cohesive cohesive, no connection between the various elements in the module, but accidentally get together.
Good coupling also divided into more of: a non-direct coupling, coupling the data, tag coupling, control the coupling, the external coupling, the common coupling, coupling the content. It represents two non-directly coupled modules not directly related to the direct contact between them and the control of calls entirely via the main module to achieve, which is the weakest coupling, the strongest independent module. Coupling data indicates that only a simple transfer of data items between a calling module and a parameter module is called, corresponds to the value passed in the high-level language. Tag coupling is also known as the coupling characteristics, indicates that the call is not a simple module and data is passed between the calling module, but the data structure, data like the name of high-level languages, and record data such as name and file name of the result, which is the name tags, in fact, the transfer of the address. Coupling the control data is not transmitted between said modules, but the control information such as a flag, switches, etc., a function of the control module of another module. Coupling the external module is a set of simple access to the same global variables, and do not pass through the information of the global variable parameter table. Content is a content directly coupled to another module access module, which is coupled to the strongest.
Design Principles High Cohesion is to say: a module to complete only a single function, as much as possible to achieve the cohesion function module.
Low coupling design principle is to say: if the coupling must exist between the modules, should be coupled with data, control the coupling less, caution or controlled use of common coupling, and to limit the scope of common coupling, the coupling to avoid content.
3, moderate design
Moderate design principle concern is to what extent the system into question. Moderate design refers to the design do not over, nor insufficient. So, over what constitutes design? What makes the design deficiencies? In short, over-design is to think too much, just want too inadequate design. Virtual feel good, is not it? I think so. Because, how to determine whether a design excessive or inadequate, and there is no standard quantifiable indicators. Therefore, the design is appropriate, that the more subjective judgment. And how to avoid over- or under-designed, more intuitive personal experience is also formed.
Inadequate design is still relatively easy to judge the cause of their insufficient design mainly two: First, because of lack of experience in the design novice caused; and second, because the blind pursuit of product features and fast implementation skipped or greatly reduced design lead.
Also some over-design the more obvious examples, such as Uncle Bob proposed Clean architecture, each point of interest have clearly defined boundaries, architecture is really clear, maintainability, testability are very good, high internal cohesion and low coupling . However, if you apply it to a small group of only two or three developers of small projects, it will obviously have found that large and complex, each need to add a small feature, but you need to write a lot of code. This is a small team for small projects, obviously not suitable. Clean architecture more suitable for more staff team, and large-scale projects.
Therefore, to determine whether the appropriate design, the status quo can not be separated teams and projects. In addition, there are other factors present situation, including a variety of business requirements, functional requirements and quality requirements. In most cases, the causes of excessive design: First, too much about the future changes that may occur; the second is the pursuit of design and design. Appropriate design should first focus on the moment, the moment of demand, the current development costs, and the status quo of the current project personnel; followed properly consider how to respond to future changes. For future changes, nor is any likely have to consider, just consider the change to a very large chance of occurring in the foreseeable future in this very large chance of up to 90%. For example, it has been determined needs to be achieved, but because of the priority issues slightly delayed; for example, have been identified staff expansion plans; for example, pairs 11 to engage in activities, trading volume will surge; and so on.
In other words, the principle of appropriate design, can be summarized as follows: Priority should be designed to meet the current needs identified, and then meet the foreseeable demand in the future will almost certainly occur. Only to meet current needs without considering the future, it is likely to lead to inadequate design; but too much to consider possible future needs, it is likely to lead to over-design. Therefore, appropriate design need to be a balance between the current needs and future needs, and I think only consider the current needs and future demand will almost certainly happen is the best balance.
---------------------
Author: bestlove13141516
Source: CSDN
Original: https: //blog.csdn.net/bestlove12345/article/details/51803053
Disclaimer: This article as a blogger original article, reproduced, please attach Bowen link!