For outsourcing business type projects, the purpose of software architecture design is different from that of product type projects. Here we mainly discuss the purpose of software architecture design of outsourcing business type projects. 1. provides the basis and specifications for large-scale development and reusable assets. The large-scale development of software system must have a certain foundation and follow certain specifications, which is not only the requirement of software engineering itself, but also the requirement of customers. In the process of architecture design, some public parts can be abstracted to form public classes and tool classes, so as to achieve the purpose of reuse. 2. Shorten the project cycle to a certain extent, and shorten the project development cycle by using the framework or reusable components provided by the software architecture. 3, reduce the cost of development and maintenance, a lot of reuse and abstraction, can extract some common parts that developers don't have to care about, so that developers can only focus on the realization of business logic, thus reducing a lot of workload and improving development efficiency. 4, improve product quality, good software architecture design is the guarantee of product quality, especially for the satisfaction of non-functional requirements often put forward by customers. Principles of software architecture design Software architecture design must follow the following principles: 1, to meet functional and non-functional requirements. This is the most basic requirement of a software system, and it is also the most basic principle that architecture design should follow. 2. Practical principle, just as every software system must be practical when it is delivered to users to solve user problems, so must the architecture design, otherwise it will be "high to high" or "over-designed". 3. Meet the requirements of reuse and maximize the work efficiency of developers. Several viewpoints of software architecture design When discussing what architecture design should do, or at the meeting of architecture design review, we often ask various questions, such as how developers should keep logs and how to control transactions. How can we improve the working efficiency of our developers, that is, complete more functions with better quality in unit time? How to meet the non-functional needs of customers? How to make the platform manager in the production environment better maintain the system? The above problems are actually raised by different stakeholders in the software system from different angles. To answer these questions, we must look at the work of software architecture design from different angles. 1. From the perspective of logic architecture and from the perspective of system users, the designed software architecture can meet the needs of business logic and deal with increasingly complex business logic requirements. 2. From the perspective of development architecture, consider the problem from the perspective of system developers. The designed architecture should be easy to understand, develop and unit test, and it is best for developers to complete functional development with the least number of lines of code. 3. From the perspective of operation architecture, considering the quality requirements of the system when it is running, especially the non-functional requirements of the system, customers often require that the longest response time of the function screen of our system should not exceed 4 seconds, which can meet the online use of 2,000 users at the same time, and the system resources are subject to role-based security control. 4. From the perspective of physical architecture, pay attention to the system installation and deployment environment, such as IBM HTTP Server+WebSphere Application Server+DB2, WebLogic+Oracle, which are the most popular enterprise application service solutions. 5. From the perspective of data architecture, all kinds of systems we developed today, such as MIS, ERP and SAP, basically operate on all kinds of data, show a bunch of data that are not well understood to users, and automatically handle all kinds of data operations, so data persistence is very important. 1. Analyze requirements, understand business model (or domain modeling), and select key use cases. Software requirements can be divided into user's perspective and developer's perspective, and can also be divided into functional requirements and non-functional requirements from the user's perspective. We must fully understand and analyze the requirements and understand the business model from different angles and levels. Practice shows that non-functional requirements, which are often ignored by us, often lead to the failure of the whole project. The best way to understand business requirements is domain modeling. Domain modeling and requirements analysis often alternate. Domain modeling mainly has the following three functions: ◆ Explore complex problems and clarify domain knowledge. Martin Fowler once said that the greatest advantage of his object-oriented method is that it helps to solve more complicated problems. Domain modeling itself, as an auxiliary thinking tool, helps us to always keep our attention on the most important business concepts and their relationships, so that we can continuously and deeply analyze and understand the requirements. Domain modeling is often a process from ambiguity to clarity, from fragmentation to system. ◆ Determine the functional scope, which will affect the expansibility. Any model is an abstraction of a program in the real world. This kind of abstraction will ignore some things, such as the attributes of objects and the relationship between objects, and these omissions are often purposeful and determine the scope of functions. The model reveals the structure behind various functions. If defining a function is equivalent to "photographing", then domain modeling is equivalent to "doing perspective", paying more attention to the internal structure of the problem domain is equivalent to abstracting the problem domain to a certain extent. A good domain model can not only support the existing functions well, but also support the new requirements that may appear in the future to a certain extent, which shows good scalability. ◆ Provide communication basis and promote effective communication. Domain modeling usually uses UML diagram as a representation, which provides convenience for our communication. Of course, sometimes words may be more appropriate and flexible in describing problems in certain fields. In the actual software development process of our company, domain modeling often lacks this link, which may be a place that needs further improvement in the future work. Although we always expect architects to fully grasp the requirements, due to the limitation of time and energy, the reality before us is that architects don't have time to analyze all the requirements in depth, so our strategy is to "use good steel at the cutting edge", that is, spend most of our time and energy on determining the most important key requirements of the architecture. When selecting key requirements, it should be noted that high-priority requirements are often viewed from the user's point of view and may not be real key requirements. In the book RUP Practitioner's Guide, it tells us how to determine the key functional requirements. A. Functions that are the core of the application or realize the main interface of the system B. Functions that must be realized, that is, if these functions are not realized, the developed software will lose its value C. Functions that cover some aspects of the system architecture but are not covered by other important use cases. 2. Consider all aspects of software architecture from different angles. Software architecture design must consider all aspects, design according to the domain model, key requirements and system constraints established in the previous work, and analyze and solve problems from the perspective of system users, developers, system administrators, deployment administrators and data administrators. For example, if our running architecture adopts cluster mode, we must be careful about the use of caching and sessions. If our business logic requires us to operate multiple databases, we should consider supporting two-phase transaction commit. Only by considering all these aspects, such an architecture design is complete. As for the details we should design in each view, it is actually related to the process definition of the whole project. For example, we have a special activity arrangement database outline design. In the process of architecture design, we can only pay attention to the higher-level database characteristics and the relationship between databases, and we can design the data dictionary of each table in the subsequent related activities, but without this activity, we will refine the relationship between each field and each table. 3. Solving key technical problems and puzzles In the process of software architecture design, we often need to overcome some key technical problems and puzzles, which requires solid theoretical knowledge and rich practical experience. For example, how to improve the performance of the whole system? How to export extremely complicated "Chinese-style reports" (generally much more complicated than those produced by western countries, and many open source BI frameworks can't completely solve the problem)? When you encounter a really difficult problem, you can go to Baidu or Google, consult senior technicians or experts of the company, or hold a small-scale technical seminar to try to find the answer by brainstorming, so as to improve work efficiency. 4. Hold an architecture design review meeting and accept peer review. Architectural design review is an extremely important part. I once described parting hook in Seven Weapons, because colleagues may ask many questions or opinions at the meeting, and many opinions are very sharp, so we must accept them with an open mind and make a good record. As the saying goes, "a good medicine tastes bitter and is good for illness, but advice when unpleasant is good for action." Before the review meeting, we must finish a lot of preparatory work. It is best to prepare a concise electronic briefing, listing the most important issues, so that the review meeting will not be aimless. We will send these materials to the participants before the meeting and ask them to take the time to get to know them first. During the meeting, we should learn to control the progress of the meeting and improve the efficiency of the meeting. 5. Implement functions on the design architecture of key use cases to verify the architecture. The verification of architecture design is also a very important work, and there are many verification technologies. In our company, we usually use the form of samples, namely iteration 0 in XP and slices in RUP. The advantage of this is that it can effectively verify whether the architecture meets the requirements from the perspective of actual products, and it can save costs compared with the abandoned prototype verification technology. This sample is by no means a patchwork of some codes that we use to do experiments when solving problems in architecture design, but a complete deliverable code, related documents that meet the architecture design and a series of specifications that realize a key use case. At the same time, this sample can be used as a teaching material when you explain or train the architecture, and can also be used as a blueprint for developers to use this architecture for development, and can even be copied and pasted with simple modifications. 6. Deliver to the customer for review. This link may not exist in many companies, because their software architecture does not necessarily need customer audit, but the most important thing for a service company like us is customer respect. The activity of implementing software architecture design is to make customers understand and accept your architecture design scheme, and at the same time, customers will also play a role in helping you verify the architecture. Usually, after our architecture is approved by customers, we can enter large-scale development. When delivering the customer review, the review may usually be conducted in the form of a meeting, so we can refer to the good practices in the review meeting and hold a meeting, so I won't go into details here. Common misunderstandings and solutions in software architecture design 1, architecture design is often "high-level". The so-called high can't be higher, in fact, our architecture design only stays in the model stage, but it is by no means the first sample scheme. 2. Architecture design is often over-designed in some aspects. A series of complicated designs have been made for some changes that will never happen at all. This kind of design is called over-design, which often brings waste of resources and increases the workload or difficulty of development. Although the expansibility and maintainability of the system should be considered, it should not be over-designed. Sometimes you may not be able to judge which designs are over-designed. At this time, you can ask your PM to help you make a decision from the height of the whole project. 3. Architecture is not a framework, nor a simple combination of several frameworks or technologies. The framework itself has an architecture. The framework is generally a semi-finished product for a certain aspect or field, which has good reusability and expansibility. We can sum it up in a classic sentence: the framework is software, the framework is not software, and the framework is a special kind of software. In our work, we can form some reusable frameworks by abstracting many reusable tool classes, public classes and basic classes. 4. Architectural design is by no means a platform for displaying new technologies. Appropriate technology is beneficial to the project, and the ability of developers and maintenance personnel must be considered. As architects, we should pay more attention to how to balance the relationship between business requirements, weaving operations (mainly teamwork) and technology, rather than just focusing on those technical details. 5. The success of architecture design determines the quality of the system. Because of poor architecture design, there are too many system bugs delivered to meet the non-functional needs of customers, and cases of project cancellation occur from time to time. Architectural design is not a matter for architects alone, nor can it be completed in a few days. It must be the result of a lot of hard work by architects, and its success or failure is often closely related to the support of organizations, supervisors and project managers. Some general skills about architectural design: 1 and the layer rule. The layer here refers to the logical layer, not the physical layer. At present, most enterprise application systems are divided into three layers, namely presentation layer, domain layer and data layer. When dividing each level, we can mainly consider the following aspects: a, each level is a relatively independent part, which can be used as a whole without knowing other levels; B, try to reduce the dependence between levels, that is, reduce coupling; C, a certain layer can have a certain degree of substitution, without much influence on other layers; D, the hierarchy can't close everything. If you add a field to the user interface, the data field will be added to the domain layer and the corresponding field will be added to the data layer. At the same time, too many layers may have a certain impact on performance. 2. There are no circular dependencies between packages. Usually, the package will be divided into different logical layers first, and then according to the functions under the package of this layer. Avoiding circular dependence between rooms is a general rule, and such a rule must have its value and reason for existence. The main reasons are: a, circular dependence will make stratification meaningless; B, circular dependence will bring many potential risks, such as the phenomenon of nested transactions (not supported by JavaEE standard). I have encountered such a problem. In the project, transactions are placed in the business logic layer for unified control. However, because developers neglected this principle in architecture, they called the public class of presentation layer in persistence layer, which led to the phenomenon of nested transactions. 3. Application of design pattern. In many people's minds, providing design patterns is equivalent to GOF's design patterns. In fact, design pattern is a broad concept, such as demand pattern, domain pattern, anti-pattern and so on. Pattern is actually a tool and a summary of people's experience in solving a certain kind of problems in the past, so we can apply various design patterns in design activities, but we must analyze the problems clearly before applying these patterns, otherwise there may be a phenomenon of "the bull's head is not right for the horse's mouth". Successful projects always have similarities, and failed projects have their own failures. Good software architecture design must be the similarity of successful projects. What is the reason why we didn't do a good job in software architecture design?