Training notes for senior System Architects

A few days ago, I attended the Advanced System Architect Training Course of instructor Xie from the training center of the Chinese Emy of Sciences computing Institute, and recorded some of the points below:

The work of the System Architect is to design complex overall solutions and the logic and physical layout of domain objects. This is a highly risky and influential activity in a complex environment.

1,Definition of software architectureSoftware architecture is also called software architecture. It is a group of important decisions related to the following elements: the organization of software systems, which forms the structural elements of the system, the choice of interfaces and their collaborative behavior, the choice of combining structured elements and behavior elements into a more granular sub-system approach, and guides this Organization (elements and their interfaces, collaboration and combination) architectural style selection. In other words, the software architecture is actually a description of the overall structure design of the system, and the System Architect is responsible for a global and overall grasp. Architecture composition and decision-making are two basic concepts of architecture design. Architecture => blueprint + rules + solution

Software architecture is a process of understanding things: Prototype, discovery, improvement, re-discovery, and re-improvement, which is a necessary spiral of software development.

2,Architect Growth Map: The System Architect is not only a skilled technical expert. He needs to work closely with the business team and be proficient in marketing, business, and management. From the perspective of rising trends, there are three layers of roadmap: first, focus on system thinking. At this level, it is important not only to grasp the knowledge points of design, but to pay more attention to the improvement of analysis and innovative thinking capabilities, and to have a broader thinking. This space is quite large. This is the first level of capability. On the second level, we should focus on summarization and guidance, and shift the thinking space to the group. How can we summarize existing experiences and make such intellectual assets play a real role? Become the second-level capability base for architects. At the third level, we need to improve our comprehensive cultivation. We must make changes in our way of thinking, cultivate organizational, leadership, innovation, and passion. This is the third level of competency for architects.

To see your own weaknesses, you must have a broad mind and think more.

The architect is not an ordinary technician. He has a higher perspective on the design site and requires more complex knowledge and capability structures, he needs methods that others do not have in mind, vision, and perception of the world. He must break through the existing mode of thinking and behavior and break through the bottleneck of his long-term thinking, it is possible to reach the level that you have never reached.

Architects should develop a good habit of recording and analyzing each task to form a more solid working style. Summary is required for each project.

3,Architects must maintain their own competitiveness: Architects must pay attention to today's IT technology and business model changes, as well as the major trends in the software industry changes that have taken place. They are diligent in thinking and meeting new challenges. The Core Competitive Advantage of a person is learning ability. As a group of senior engineers at the technical level, architects must pay attention to the following questions to maintain their competitiveness: (1) Maintain passion: The Key is faith. Passion is derived from belief. If you have faith, you can take the initiative to challenge yourself. If you meet the challenge, you will have passion. If you have passion, you will be more interesting. (2) Innovative Thinking: trying new methods at work is an important means to maintain self-ability. (3) Reverse Thinking: Reverse Thinking refers to analyzing the same problem in a way that is opposite to the normal thinking, so as to diversify the thinking. Reverse Thinking can help people break through the limitations of traditional thinking and overcome the inertial way of thinking. In the opposite direction, unexpected results are often obtained.

4,Architects should pay attention to new software trends: At present, the problems exposed by the traditional software crisis have not been solved, but new challenges have been put at the forefront. As people constantly think about the challenges and countermeasures, they have formed some new trends, including: (1) software quality is presented in the form of service quality, investment in quality can achieve higher return on investment. (2) software processes are extended to users, and more users are expected to participate in the entire software lifecycle. (3) Functional supremacy is far from enough, and the user experience has received unprecedented attention. (4) as the system integration model is facing a revolution, software, services, terminals, and IT infrastructure will form a closer value system. (5) R & D should focus more on non-functional requirements, such as security quality, performance, reliability, scalability, scalability, and availability, so as to continuously improve the value of software.

Knowledge is power => Information is power

The architecture is not entirely an outline design. The outline design remains on the drawing, and the architecture must prove that this technical route is feasible and can prove that most quality risks have been solved.

5,The so-called design is the process of solving the problem: Software design is a kind of thinking activity. The charm of design lies in the ability to solve problems. By facing the challenges of the problems and carefully reviewing the corresponding solutions, it is possible to design truly spiritual products. (1) design is not universal: software design is rarely general, and different goals need to be supported by different designs. (2) Balance: software design is essentially a balance between quality, cost, time, and other factors. (3) record the reason for design (design documents ).

Focus more on Architecture Design in various aspects

6,The quality attribute determines the architecture style.: An architectural style is largely related to how the designer meets the quality requirements. Both functional and non-functional requirements may have quality requirements. The quality attributes related to functionality mainly include: A. correctness: the ability of the software to correctly execute tasks as required. B. Robustness: it refers to the ability of the software to run normally in case of exceptions. The difference between correctness and robustness is that the former describes the problem within the functional requirements, while the latter describes the problem beyond the functional requirements. Robustness generally has two meanings: Fault Tolerance and recovery. Fault Tolerance refers to the ability to avoid errors when an exception occurs, and recovery refers to the ability to restore the software to a state where no error money occurs after an error occurs. C. Reliability: it is a time-related attribute. It refers to the probability that the system will not fail for a certain period of time in a certain environment. Generally, the average fault-free time is used. (2) quality attributes related to non-functionality mainly include: A. Performance: it refers to the "time-space" Efficiency of the software, not just the software running speed. In other words, the speed is faster and the resource usage is less. Performance = speed/resource. B. ease of use: it refers to the ease of use of software by users. C. Clarity: the work results are easy to read and understand. D. Security: The purpose is that the system should be able to prevent illegal intrusion, which is a technical and management issue. E. Scalability: this reflects the software's ability to adapt to "Changes", including requirements, design changes, algorithm improvements and changes. F. Portability: it refers to the ability that the software can be used in different software and hardware environments without modification (or slight modification.

7,Resist the temptation to carry out a huge design in the Early Stage(1) The architecture should be easily evolutionary; (2) the project development cycle should not exceed 6 months; (3) divide and conquer: GRASP real needs, divide and conquer (divide large projects into small projects), set priorities, and deliver as soon as possible; (4) incremental development and delivery: if the preliminary requirements are clear, A large project can be divided into several relatively independent parts that can be continuously delivered, so that the big problem can be divided into several small problems; (5) iterative development and delivery: if the demand in the early stage is not too clear and the project has a strong innovation component, you can use a model with strong iteration and progressive refinement.

8,Reconstruction: Without affecting the overall external behavior, we constantly make minor design improvements to the software. This progressive practice is called refactoring. Refactoring not only reduces maintenance costs, but also provides us with general standards for improving code quality and allows us to quickly add new features. In essence, restructuring is fundamentally an attitude issue, not a technical issue.

After you concentrate on the Code logic, you need to focus on the second thing, that is, refactoring. During code refactoring, we will not add new features or even fix bugs. Instead, we can improve the readability of the Code by making the code easier to understand.

Rebuild should be persistent: (1) rebuild can speed up the progress; (2) rebuild should be carried out in a small step; (3) the more technical debt accumulation, the more difficult the rebuild will be.

9,Basic principles for Structure Optimization: After the functional logic is completed, in addition to code refactoring, You need to review the software structure in many cases to reconstruct the structure. Good structure design should follow some principles, and the Principles themselves are a summary of experience. Based on these principles, we can have a good design orientation in the design. If the requirements remain unchanged, no structure is required.

Four Design Principles of the structure: (1) single responsibility principle (SRP): Also known as cohesion principle; the SRP principle is described as: for a class, there should be only one reason for its change; (2) open-closed principle (OCP): the Key to OCP is to rely on abstraction. The purpose of the OCP principle is to require that the software entities (classes, components, functions, and so on) We design be extensible, but not modifiable. A. Open for expansion: this means that the behavior of components can be expanded. When the demand of applications changes, we can expand the components, give it new actions that meet those changes. In other words, we can change the functions of components. B. changes are closed: you do not need to modify the source code of the component when you expand the component behavior. No changes are required for dynamic link libraries, DLL files, or Java jar files. (3) Dependency inversion principle (DIP): using the dependency structure created by the traditional structural design, the strategy depends on details, which is bad, this will affect the policy details. Object-Oriented Programming reverses the dependency structure, so that the details and policies depend on abstraction, and customers often have service interfaces. In fact, the inversion of this dependency is exactly the sign of a good object-oriented design. The principle of DIP is: A. High-level components should not depend on low-level components. Both of them should depend on abstraction. B. abstraction should not depend on details, and details should depend on abstraction. (4) interface isolation principle (ISP): This principle is used to deal with the shortcomings of the "fat" interface. The "fat" (no cohesion) interface of the class can be divided into multiple groups of methods. Each group serves a different set of customer programs. In this way, some client programs can use a group member function, while other client programs can use a group member function. Actually, there are also some objects, which do not need cohesion interfaces, but the ISP suggests that the client program should not see them as a single class. On the contrary, the client program should see multiple abstract base classes with cohesion interfaces.

10,Focus on changes and features: Designed to embrace changes. Changes will always change as an important design element. Object-oriented is a way of thinking. Design Based on interfaces.

Softwarereuse (softwarereuse): it refers to the use of various related knowledge of existing software to create new software to reduce the cost of software development and maintenance. Software reuse is an important technology to improve software productivity and quality. Early Software Reuse mainly involved code-Level Reuse and reusable knowledge-specific programs, later, it expanded to covering domain knowledge, development experience, design decisions, architecture, requirements, design, code and documentation, and other related aspects.

Software reuse refers to the process in which identical or similar software elements are repeatedly used in two or multiple different software development processes. Software elements include program code, test cases, design documents, design processes, documents to be analyzed, and even domain knowledge. Generally, reusable elements are also called software components. The larger the reusable software components, the larger the granularity of reuse.

11,Service-Oriented Architecture (SOA): Service-Oriented Architecture is successful in service identification. Basic Process of service identification: (1) understanding the nature of the project; (2) taking the lead in the business; (3) Clarifying the strategic objectives of the product; (4) study business processes of enterprises; (5) Reuse of industrial products; (6) Establishment of contract baselines; (7) improvement of service attribute level matrix (ARMS); (8) use business agile Scenario Simulation (bass) for testing; (9) embrace changes.

12,Differences between architecture and framework: The Framework is a software, but the architecture is not software, but an important decision about how to design the software. However, after the introduction of the software framework, software architecture decisions are often reflected in the Framework Design. Both architecture technology and framework technology are the results of "divide and conquer" to solve the difficulties brought about by increasingly complex software. The architecture thinking is first about the overall situation and then about the local area. This is a problem in the abstract layer. First, consider the overall situation and ignore the details. The Framework is intended for use first and then for use. It is a semi-finished product and can become a specific software only after customization.

The relationship between the framework and the architecture can be summarized into two aspects: (1) to verify the architecture design as soon as possible, or to support product line development, the general mechanism or even the entire architecture can be implemented in the framework; (2) Enterprises may have a large number of reusable frameworks, which may have implemented the important mechanisms required by the architecture or provided extensible semi-finished products for a subsystem, the final software architecture can be constructed using these frameworks.

The most important part of framework design is not what technical solutions are used for implementation, but an in-depth consideration of existing business processes to find their commonalities and explore the rules, establish an appropriate model and select an appropriate technical implementation solution.

Key factors include determination, means (methods), passion, and confidence. Technology is not a key factor.

13,Sum up experience into Theory(1) summary process: summarizes the steps that must be followed for a good design, and the goal of each step, the problems to be solved, the points of thinking and the direction of thinking. (2) Summary mode (design mode): This mode is a summary of practical experience. By summarizing various solutions for each thinking Point and assembling them with the process nodes, form a Model language that can guide others.

At present, there are more than 110 design models. The model is not a dogma, but a summary of experience.

The mode is a named Summary of the formatting experience of the solution, which can effectively help us to sum up and use experience.

14. In software design, the top-down architecture can be divided into three major process domains, including top-level architecture design process domains and domain object design process domains; resource application design process field, Figure 1.

Figure 1

The purpose of the top-level architecture design process domain is to establish a conceptual architecture of the system, describe an initial outline of the system, and make decisions on global problems.

The goal of the domain object design process domain is to portray each domain object at the detail Layer Based on the refined domain object model, and to make decisions on technical issues at these detail levels.

The purpose of the resource application design process domain is to make decisions on solutions and problems involving memory, objects, and data at both the macro and micro levels.

For further refinement, a series of processes can be included within each process domain (for solving a specific topic and problem, called a process ). In this way, the macro design process can be divided into 11 Group aggregation processes (problem domains ). Although the process description is clearly separated, the design of the entire software is not just a process of gradual refinement from top to bottom, it is a process of continuous feedback that affects each other, supports each other, and constantly optimizes the design process, as shown in figure 2.

Figure 2

Design Mode Summary:

Domain Model: defines an exact model of the application domain structure and workflow, including their changes.

Layers: solves the problem of reasonable hierarchy of the system.

Model-View-Controller: solves the problem of support for user interface changes. Supports changes to a specific user interface.

Presentation-processing action-control: solves multiple forms of problem with the same business.

Microkernel: solves the problem of multiple business methods.

Refelection: solves the problem of dynamically changing the structure and behavior of the software system.

Pipes and filters: solves the problem of algorithm structuring and re-building.

Shared Repository: Applicable to network management and control systems.

Blackboard: solves the problem of intelligent improvement methods in operation.

Domain object: The domain object has encapsulated self-complete coherent functions and basic responsibilities into well-defined entities and provides functions through one or more "Display Interfaces, and hide the internal structure and implementation.

Messaging: a series of interconnected messagechannels and message router manage message exchanges between different services across networks.

Message Channel: solves the problem of connecting clients and services that cooperate with each other.

Message router: solves the problem of how to accept "channel" messages according to conditions.

Message Translator: solves the problem of how to convert the Message format.

Message endpoint: solves the problem of converting data into a form that can be understood by message-oriented middleware.

Publisher-subscriber: To better notify other domain objects of events of mutual interest in applications.

BROKER: manages all key aspects of remote interoperability between objects in the domain through a proxy manager.

Client proxy: solves the problem of mutual shielding between client applications and network infrastructure.

Requestor: solves the problem that application code is contaminated by infrastructure code and affects portability.

Invoker: solves the problem that service code is contaminated by infrastructure code and affects portability.

Client request handler: solves the problem of mutual influence between client applications and communications. It encapsulates the details of inter-process communication performed by the client behind a unified interface.

Server request handler: solves the problem of mutual impact between applications and communications on the server, and encapsulates the details of inter-process communication performed by the server side behind a unified interface.

Reactor: solves the problem of avoiding multithreading in applications.

Proactor: solves performance problems in the multi-thread background.

Acceptor-connector: separates event initialization from specific processing methods to improve maintainability.

Asynchronous completion token: solves the problem that events that arrive asynchronously can still be processed in a certain order.

Explicit interface: solves the problem of correct interface design.

Extension interface: over time, component interfaces expand and a fat interface becomes more vulnerable. Prevents "fat" interfaces and isolates them.

Introspective interface: solves the problem of exposing internal information interfaces.

Dynamic invocation interface: solves the problem that the same interface allows the client to call multiple methods.

Proxy: solves the problem of blocking some implementations through proxy under the same interface.

Business Delegate: a local business representative completes all network tasks, separates applications and network processing services, reduces development difficulty, and improves comprehensibility and maintainability.

Facade: solves the problem of shielding subsystems from changes to high-level applications.

Combined Method: Solves the unreasonable distribution problem of multiple correlated methods.

Iterator: solves the problem of convenient iteration of distributed elements.

Enumeration Method: solves the problem of reducing the independent access overhead of elements in the aggregation for multiple external iterations.

Batch Method: solves the problem of increasing network overhead for multiple accesses.

Encapsulated implementation: Solves the basic principles and methods of object division.

Composite: establishes a flexible tree structure object organization form to form a "whole/part" hierarchy.

Half-object plus Protocol: rationally distributes objects in a distributed system to reduce unreasonable network traffic and server pressure.

Replicated component group: Solves the fault tolerance problem of the distributed system. The copied components are deployed on different network nodes and form a component group.

Half-sync/half-async: Understand coupling between asynchronous and synchronous services in a concurrent system to simplify programming, without compromising performance excessively.

Leader/followers: solves the problem of reducing concurrent thread applications in a large batch of small processing environments.

Active Object: to reduce the number of concurrent thread applications on the server.

Monitor object: Solves the issue of coordination between concurrent services.

Guarded suspension: In a concurrency program, when a thread accesses a resource, it must first determine whether the alert condition for this resource is true.

Future: the service that calls concurrently may need to return results to the client.

Thread-safe interface: Avoid self-deadlock and lock overhead.

Strategized locking: when creating or declaring a lock instance, configure an appropriate type for the component. Use this lock instance to protect all critical zones in the component.

Scoped locking: Solve the deadlock problem caused by accidental release in complicated and complicated code.

Thread-specific storage: solves performance problems caused by frequent object usage and repeated lock unlocking.

Copied value: Solves the performance problem caused by the shared value object being locked.

Immutable value: Solves the performance problem caused by the shared value object being locked.

Observer: defines a specific update interface. Through this interface, the observer receives the subject status change notification.

Double DISPATCH: determines the process of calling a method based on the type of multiple objects at run time.

Mediator: encapsulates the aggregation and collaboration behavior of all objects in the set to decouple these objects.

Command: defines a common interface for these objects to execute the requests they represent.

Memento: solves the problem of correctly storing and reading distributed object States without compromising encapsulation.

Context object: solves the problem of sharing common information related to the execution context in a loosely coupled system.

Data transfer object: Solves the huge overhead caused by multiple fine-grained calls to access a single attribute of a remote object.

Message: The network protocol only supports the simplest form of data transmission such as bit stream, and cannot identify service calls and data types.

Bridge: solves the problem of embedding the last changed part in the lower-layer stable business.

Object Adapter: solves incompatibility problems caused by interface changes.

Chain of responsibility: solves the problem that changes in the object structure and request Distribution logic affect the client.

Interceptor: solves the problem of building a pluggable framework change model.

Visitor: solves the problem that it is difficult to centrally process Service implementations in various classes that define object structures.

Decorator: solves the problem of adding extensions to the periphery of stable core functions.

Template Method: solves the problem of embedding the last changed part in the stable business at the lower layer.

Strategy: solves the problem of executing different behaviors in one or more methods based on different situations.

Wrapper facade: mainly solves the problem that the application code uses the services provided by the underlying API but the code is hard to understand. It needs to encapsulate the underlying API in an object-oriented manner, it provides a concise, robust, portable, and cohesive object-oriented interface to encapsulate functions and data.

Declarative component configuration: Establishes the host infrastructure that requires various plug-ins to correctly manage the runtime environment and use system resources and services reliably.

Container: solves the problem that the platform environment for direct processing of domain objects is closely coupled with the platform and increases the complexity of implementation.

Component configurator: solves the problem of re-configuring components after the component lifecycle and during upgrade.

Object Manager: solves the problem of increasing the Coupling Degree and complexity of applications by relying on Object Management on the client.

Virtual Proxy: solves the problem of loading all objects from a large database and consuming a large amount of resources.

Resource Pool: Solves the performance overhead introduced by obtaining and releasing resources (network connections, threads, or content.

Resource cache: solves unnecessary performance overhead caused by frequent creation and release of resources by users with limited resources.

Automatic garbage collection: solves the problem that the memory that is no longer in use may be used up in a timely manner.

Counting handles: This solution ensures that shared objects created on the stack can be reliably, securely, and timely recycled.

Abstract Factory: solves the problem of creating and destroying a batch of objects in a uniform way.

Builder: This solution simplifies the complexity and diversity of object creation in multiple steps.

Factory method: Solves the issue that directly creating an object may cause code confusion and affect the independence of the calling code.

Disposal Method: solves the problem of excessive coupling that may take multiple steps to destroy objects.

Database access layer: It separates the object-oriented application design from the relational database by introducing a ing layer between the two types.

Data mapper: solves the problem of full decoupling between the data model and the persistent table structure.

Row data Gateway: solves the problem of full decoupling between more detailed data models and persistent table structures.

Table Data Gateway: completely decoupled between more detailed data models and persistent table structures.

Active record: solves the problem of reducing the coupling between the Object-oriented Data Model in the application and the table structure in the database.

Training notes for senior System Architects