Talking about Architecture Methodology

|0x00 Architectural Thinking

I believe many people, when talking about architecture, their first impression is that there are various architecture diagrams. There is a person who is above all sitting there and talking about his ideas. It is true that drawing pictures is a daily work of architects, but it is another kind of skill to show the essence of the development of things through a picture. After working as a programmer for so many years, if you only open Idea before you can think about the architecture, or you can understand the business if you type the Sql code, you can only think about it because you can’t understand it.

The first impression of the architecture should not be how popular the technology or the high-performance framework is, but whether it can meet the needs of the business, and it can neither run nor be too advanced.

So what is the architecture? In theory, it describes the abstract relationship between different entities in the system. Abstraction is actually very important, because it is very difficult to explain a complex business model to a software engineer, or product manager, or customer. At this time, the business model is simplified and abstracted into ordinary "words", so that everyone can accurately understand and recombine, and productivity will burst out.

Furthermore, the architecture of the software process has two goals: "reducing the entropy of the system" and "supporting rapid expansion." Software development is a multi-party cooperative system project. The more complete the function, the higher the complexity of the system, the more difficult the management, the higher the probability of problems. How to systematically reduce the cognitive load of the system is to "reduce the entropy of the system". For those who continue to develop, the higher the increase in productivity. But the demand will not be static. The ideal state is like a cloud service, and continuous expansion can solve all problems. Therefore, the continuous emergence of concepts such as "componentization" and "microservices" is also an attempt to make reservations for expansion for uncertain future needs.

The core of architectural thinking is to solve the problem of complexity and find a balance in the process of solving: it must be simple and satisfy development. This kind of balanced thinking is definitely not something that can be cultivated in a day or two. It is also everywhere in life: how to balance life and work, how to balance weight and appetite, how to balance rest and study... There is no other, but hands are familiar.

|0x01 System Analysis

After having an in-depth understanding of the business, the next step is to conduct a system analysis and disassemble the details of the business. There are many ways of system analysis, but in general, there are two most commonly used: one is "bottom-up" and the other is "top-down".

"Bottom-up" means that there are specific problems first, and then they are abstracted through analysis. In their daily work, development students have to deal with a variety of needs every day. Some are from the business side, some are from brainstorms, and some are from regular function iterations. Then after the details of these requirements come, we need to start the abstract process, which is a rigorous derivation process, that is, business modeling + application logic = system architecture. Business modeling usually requires the accumulation of knowledge in a certain field, such as advertising and sales, finance and loan cash flow, e-commerce and SKU payment, etc. Collect more business knowledge in related fields, build the smallest business unit common in the industry, and deduce the top-level structure step by step, which is of great help to business modeling. The other part is application logic, such as object-oriented design methods, to extract reusable modules and stable dependencies, which partly depends on the experience accumulation of developers.

"Top-down" refers to the first abstract concept, and then step by step dismantling to the specific approach. This derivation method relies on the "accurate definition of the problem." Generally speaking, there are several stages to refer to: accurately ask the question-imagine the demand question-have a dialogue with the demand side-refine the new demand question-continue the dialogue with the demand side. For example, Chesterton mentioned the example in "Pyramid Principle": "How does the secretary arrange a meeting of three people".

This is the thinking of normal people:

this is the thinking of the pyramid:

"If you think it through, you can speak, and if you speak, you can do things."

When we design the architecture, we usually get the requirements directly from the product or business side. In the process of decomposing the problem layer by layer, some links can be directly defined as technical problems, but there are always some specific functions. The requirements are described in business language, and this part needs to be reconciled and confirmed before being transformed into technical problems. In the end, a big demand is broken down into several technical sub-problems to complete the "top-down" derivation of the architecture.

|0x02 Architecture Design

The current mainstream enterprise architecture theory is "TOGAF". About 80% of Forbes' global top 50 companies are using it. Foreign companies such as SAP, IBM, HP, and Oracle are promoting it, and domestically, it is being promoted by Kingdee and Dasoft. .

As can be seen from the above figure, TOGAF emphasizes four areas of design:

• Business architecture (Business): develop a business framework and support the agreed architecture vision;
• Data Architecture (Information): Define the structure of the architectural continuum in the organization;
• Application architecture (Application): describe the functions and services used to support this sustainable architecture;
• Technical architecture (Technical): Develop a technical architecture, establish baselines and goals as they are, and analyze gaps.

After using theoretical guidance, let’s briefly describe the daily workflow:

1. Design tools: "Workers must first sharpen their tools if they want to do well." Architecture can be too difficult without tools to aid thinking. In system design, the UML unified modeling language is the first to be promoted. The biggest feature of UML is that for different fields, the essential elements used are the same, and everyone can understand business and requirements based on a common "model."
2. Demand analysis: In the demand analysis stage, “profit analysis” must be carried out first, especially in the face of multi-directional business delivery, it is necessary to seize the most important beneficiaries of the system and do a good job in the lead distribution of benefits; "Assessment" includes human and machine resources; once again, the "requirements specifications" are sorted out. This step is for technical personnel. A series of specifications are adopted to ensure that developers' understanding can accurately match the needs of business parties.
3. Model establishment: The purpose of modeling is to replace complex business reality by constructing simple models. There are many modeling methods: domain-driven (DDD), use-case-driven (UDD), four-color modeling, and so on. The modeling process allows the knowledge that needs to be used in the domain, such as permissions, crowds, activities, etc., to match specific business processes: authorization, circle selection, marketing rules, etc. Through the modeling method and digesting the specific domain knowledge, we can output the final domain model diagram.
4. Architecture output: This step mainly includes program description, design constraints, technology selection, system structure, data design, etc. Finally, we can determine the general architecture type of the technology, such as layered architecture (MVC), microservice architecture, cloud native architecture, etc.
   

|0x03 Architecture landing

The process I wrote just now seems ordinary, but it is all a high-level summary of the predecessors' experience in software development, and it is the essence. And condensing these simple principles into principles to guide the daily development and design of technical personnel, so that we can handle no matter how complex software systems we face, it is the cornerstone of the architecture that can truly land. .

The design principles that everyone knows daily, also called SOLID principles, mainly fall into five categories:

• Single responsibility: There is only one reason for changing the class. That is, each class has only one type of responsibility. When this class has multiple responsibilities, the class should be decomposed.
• The principle of opening and closing: open to expansion, and closed to modification.
• Li-style substitution: Try not to override the methods of the parent class as far as possible. The child class can extend the functions of the parent class, but cannot change the original functions of the parent class.
• Interface isolation: Using multiple dedicated interfaces is better than using a single total interface.
• Dependency inversion: high-level modules should not depend on low-level modules, and all these should depend on abstraction, that is, abstraction should not depend on details, and details should depend on abstraction.

Another type of recommended learning model is the GRASP principle, also known as the principle of responsibility assignment, which can help us understand the design of basic objects:

• Creator: Who should create an instance of a certain type.
• Information experts: Assign responsibilities to classes that have the information needed to complete the responsibilities.
• High cohesion: Assign cohesive responsibilities to classes as much as possible, which can also be said to be functional cohesive responsibilities.
• Low coupling: reduce the connection between classes as much as possible.
• Polymorphism: When related choices or behaviors vary with types, use polymorphic operations to assign responsibilities to changing behavior types.
• Pure fiction: Cohesion and coupling are coordinated by a pure fictional class.
• Indirect: "The internal classes of two different modules cannot be directly connected", but we can indirectly connect two different modules through the intermediate class.

|0xFF Architect

Finally, let's talk about the most important skill of an architect: trade-offs and learning. It is necessary to meet future developments while avoiding over-design. For example, in data development, the meaning of real-time does not necessarily mean that a real-time calculation framework must be used. Improved query speed through OLAP engines, or 15 minutes/30 minutes to update data, can also satisfy most sensory "real-time calculations" ".

For architects, improving the ability to think about technology and the understanding of solutions in the corresponding field is the lowest level ability. Even if it is a pure framework or a development position related to pure architecture, it is increasingly emphasized to be close to the business. . In the usual large number of business development processes, there are always two biggest difficulties: one is the complexity of logic, and the other is the variability of requirements. Many times Pu, take the initiative to think with questions, who are the customers? What is the appeal? Is there a better solution? After a long period of deliberate training, the improvement of ability is a natural thing.